New features in Android Studio Preview

This page lists the new features introduced in Android Studio preview releases. The preview builds provide early access to the latest features and improvements in Android Studio. You can download these preview versions here. If you encounter any problems using a preview version of Android Studio, please let us know. Your bug reports help to make Android Studio better.

For the latest news on Android Studio preview releases, including a list of notable fixes in each preview release, see the Release Updates in the Android Studio blog.

Current versions of Android Studio

The following table lists the current versions of Android Studio and their respective channels.

Compatibility with Android Gradle plugin previews

Each preview version of Android Studio is published alongside a corresponding version of the Android Gradle plugin (AGP). Preview versions of Studio should work with any compatible stable version of AGP. However, if you're using a preview version of AGP, you must use the corresponding preview version of Studio (for example, Android Studio Chipmunk Canary 7 with AGP 7.2.0-alpha07). Attempts to use divergent versions (for example, Android Studio Chipmunk Beta 1 with AGP 7.2.0-alpha07) will cause a Sync failure, which results in a prompt to update to the corresponding version of AGP.

For a detailed log of Android Gradle plugin API deprecations and removals, see the Android Gradle plugin API updates.

Android Studio Flamingo | 2022.2.1

The following are new features in Android Studio Flamingo.

Themed app icons and dynamic color

With the introductions of dynamic color in Material 3 and themed app icons in Android 13, you can now create layouts or launcher icons that are tinted to inherit the coloring of the user's chosen wallpaper. You can use this feature starting with Android Studio Flamingo Beta 1.

Themed app icons preview support

For launcher.xml files, you can now use the new System UI Mode selector on the toolbar to switch wallpapers and see how your themed app icons react to different users' chosen wallpaper.

Dynamic color preview

For Compose Preview: We've added a new attribute, wallpaper, to the Composable Preview annotation. If you've enabled dynamic color in your app, you can use this new attribute to switch wallpapers and see how your UI reacts to different users' chosen wallpaper. To use this feature, you must use Compose 1.4.0-alpha03 or higher.

For Android XML: If you've enabled dynamic color in your app, you can now use the new System UI Mode selector on the toolbar to switch wallpapers and see how your layouts react to different user's chosen wallpaper. Note that you must first select to change the theme to a Material dynamic color theme, then change the wallpaper.

Updates to Live Edit

Live Edit now has two modes: manual and automatic. In manual mode, your code changes are applied every time you manually save using Ctrl + S (Command+ S for macOS). In automatic mode, when you update a composable function, your changes are applied in your device or emulator as you make that change. To choose the mode you want to run Live Edit in, go to File > Settings from the menu bar (or Android Studio > Preferences on macOS), click on Editor > Live Edit, and check the Push Edits Manually or Push Edits Automatically box.

Compose Tracing

The System tracing utility is an Android tool that saves device activity to a trace file, which provides an overall picture of your app's system processes for a given period of time. Starting with Android Studio Flamingo, you can view your Compose functions in the System Trace profiler using Compose Tracing. Compose Tracing gives you the low intrusiveness from System tracing with method tracing levels of detail in composition, helping you understand which Compose functions are actually being recomposed.

To get started with recomposition tracing, you need to update to at least the following versions:

• Android Studio Flamingo Canary 5
• Compose UI: 1.3.0-beta01
• Compose Compiler: 1.3.0
• The device or emulator you run your trace on must be at least API level 30.

Additionally, you need to add the following dependency on Compose Runtime Tracing:

implementation("androidx.compose.runtime:runtime-tracing:1.0.0-alpha01")

To view recomposition tracing, open the Android Studio Profiler and select the CPU profiler. Navigate your app to the UI that you want to trace and then select System Trace and Record. While recording, use your app in order to cause recomposition. Once you stop recording and the trace processes, you can see the Compose functions in the recomposition trace directly in the Threads timeline. You can also see the Compose functions in the Flame Chart, Top Down, Bottom Up, and Events tabs from the Analysis pane.

This is an experimental feature in active development, and we welcome you to provide feedback. For more details, see Compose tracing.

Updates to project templates

Android Studio Flamingo Canary 6 includes new templates for creating a project or module. By default, templates use Compose Material 3 unless they are specified as a Views template. We recommend using the Compose Material 3 templates (for example, Empty Activity) as the best practice for creating an Android app. To learn more, see the Compose Material 3 reference.

To view the templates, go to open the New Project or Create New Module wizard by selecting File > New > New Project or New Module from the main menu.

Network Inspector traffic interception

Starting with Android Studio Flamingo Canary 1, the Network Inspector shows all traffic data for the full timeline by default. You can select a range within the timeline to see only the traffic in that range.

You can also create and manage rules that help test how your app behaves when encountering different responses such as status codes, and response headers and bodies. The rules determine what responses to intercept and how to modify these responses before they reach the app. You can choose which rule to enable or disable by checking the Active box next to each rule. Rules are automatically saved every time you modify them.

To get started, navigate to the Rules tab in the Network Inspector and click + to create a new rule. In the Rule Details panel, name your new rule and include information about the origin of the response you want to intercept under the Origin subsection. The URL in the Rules table should update based on the changes you made to the origin of the response. All fields in this subsection are optional.

From the Response subsection, you can modify the response before it's sent to your app. For example, you can set the rule to execute on responses with a specific status code as well as modify that status code.

Modify headers

In the Header rules subsection, you can create multiple sub-rules that add or modify headers in a response. When you create multiple header rules, use the up and down arrows at the top of the Rules table to change the order of the header rules. The order affects the header of the modified response because the header rules are applied in the order that they are listed.

To get started, click + in the Header rules section.

To add a header, enter a name and value for the header in the Add new header section.

To modify a header, navigate to the Edit existing header tab and specify the header name or value that you want to find. Enter a header name or value that you want to replace it with.

Modify response body

You can also create sub-rules to modify the body of the response. You can choose to either Find and Replace a section of the body, in which the first instance in the body is replaced; or, you can choose to replace the entire content of the body by selecting Replace entire body.

Similar to Header rules, you can create multiple body rules that are applied in the order that they are listed in the table.

Auto-connect to foreground process in Layout Inspector

The Layout Inspector now automatically connects to apps on virtual or physical devices. Specifically, the Layout Inspector automatically connects to debuggable processes running in the foreground of a connected device. If you have feedback on this feature, please file a bug.

Updates to App Quality Insights

Android Studio Flamingo Canary 5 and higher introduce multiple new App Quality Insights features that help you focus on high priority issues and collaborate with your development team.

New filters and filter search

To help you identify the most important issues, you can now filter by the following attributes. Each filter is sorted by the number of events, so you can see where most events occur.

• Android platform version
• Device make and model

• Crashlytics Signal: Signal icons also appear next to associated issues in the Issues panel so you can see counts and signals side by side. An issue is considered regressed when it's been closed in the past and has reoccurred in a new version of the app.

  

• App version: This filter now includes a higher-level Play track filter that you can use to automatically select versions in the production, open, closed and/or internal testing tracks.

In addition, filters with lots of options are now searchable so you can customize your view faster, without scrolling through all the menu options.

Annotate and close issues directly from Android Studio

To make it easier for you to collaborate with teammates, you can now do the following directly in the App Quality Insights tool window:

• Close issues. To close an issue, click the Close button in the main stack trace panel. Recently closed issues appear in the Issues panel with strikethrough. You can reopen issues that have been recently closed by clicking on the button again. However, once you refresh the App Quality Insights tool window, closed issues are no longer visible.

• Read and attach notes to issues so that they are visible in the Firebase Console and your teammates. To write a note about an issue, select the issue and open the Notes panel. You must have write permission to the Crashlytics project in order to write notes. Issues with notes appear with a "notes" icon in the Issues panel.

If you're new to App Quality Insights and would like to learn more, see the earlier release note.

Investigate with limited functionality when offline

Starting with Android Studio Flamingo Canary 8, you can do some actions in the App Quality Insights tool window while offline. If you make a new request, such as by clicking Refresh, and Android Studio is unable to communicate with Crashlytics, the App Quality Insights window allows you to enter Offline Mode.

While in this mode, you can continue to investigate issues and the latest events from cached data. Certain functionality, such as changing some filter options or closing issues, is not available. To retry your connection to Crashlytics and return to an online state, click Reconnect.

Known issues

The following are known issues with the App Quality Insights preview features.

Incorrect data for apps not published to Play Console

For apps that aren't associated with one or more Play tracks, you might see incorrect data, such app versions and event counts, when selecting a Play Track from the dropdown filter. App versions that are associated with Play tracks should, however, show accurate information. We're currently working on fixing this issue.

Filter search is case-sensitive and limited in scope

The filter search behavior is case-sensitive. It also only searches the top-level fields, for example "Google," and not the sub-fields, for example "Pixel 5." We're currently working on fixing this issue.

One-click automated profileable build and run

Android Studio Flamingo and AGP 7.3 introduces one-click automated profileable builds, which makes it easier to configure a profileable app and profile it. This feature requires a virtual or physical test device running API level 29 or higher. To use the feature, click the arrow next to the Profile app icon and choose between two options:

• Profile 'app' with low overhead starts the CPU and Memory profilers. In the Memory profiler, only Record Native Allocations is enabled.

  

• Profile 'app' with complete data starts the CPU, Memory, and Energy profilers.

  

To learn more about testing your app with minimal performance costs, see Profileable applications.

Breaking changes related to build

The following are breaking changes related to how you configure your build. To get help adjusting your code to support these changes, use the AGP Upgrade Assistant (Tools > AGP Upgrade Assistant).

Default values of flags changed

The default values for the buildFeatures.renderScript, buildFeatures.aidl, and buildFeatures.buildConfig flags have changed from true to false. If you need to enable these features, make sure that they're explicitly set to true. These build features should be enabled only in the modules that use them.

To support these changes, the AGP Upgrade Assistant takes the following actions:

• For modules that use AIDL compilation or RenderScript, the Upgrade Assistant automatically sets the appropriate flags to true.
• For projects that use BuildConfig and haven't opted in to the new behavior, the Upgrade Assistant sets a global flag to preserve the AGP 7.x behavior.

R class defaults changed

There are two breaking changes related to R classes:

• R classes are now non-transitive by default. They only contain the resources defined in the module.
• R class values in R classes are now non-constant by default.

If you haven't already opted in to the new behavior, the AGP Upgrade Assistant prevents these changes from breaking your project by setting a global flag to preserve the AGP 7.x behavior.

Namespace required in module-level build.gradle file

You must set the namespace in the module-level build.gradle file, rather than the manifest file. You can start using the namespace DSL property starting with AGP 7.3. To learn more, see Set a namespace.

When migrating to the namespace DSL, be aware of the following issues:

• Previous versions of AGP infer the test namespace from the main namespace, or application ID, incorrectly in some cases. The AGP Upgrade Assistant blocks the upgrade if it finds that your project's main namespace and test namespace are the same. If the upgrade is blocked, you need to manually change testNamespace and modify your source code accordingly.
• After you change the test namespace, it's possible that your code compiles but your instrumented tests fail at runtime. This can happen if your instrumented test source code references a resource defined in both your androidTest and app sources.

For more information, see issue #191813691 comment #19.

Build Analyzer task categories

Starting with Android Studio Flamingo, Build Analyzer has a new default view for tasks that impact build duration. If your project uses AGP 8.0 or higher, instead of displaying tasks individually, Build Analyzer groups them by category. For example, tasks specific to Android Resources, Kotlin, or Dexing are grouped together and then sorted by build duration. This makes it easy to know what category has the most impact on build time. Expanding each category displays a list of the corresponding tasks. To display tasks individually, without grouping, use the Group by drop-down.

New settings plugin

AGP 8.0.0-alpha09 introduces the new settings plugin. The settings plugin lets you centralize global configurations—configurations that apply to all modules—in one place so you don't need to copy and paste the configurations in multiple modules. In addition, you can use the settings plugin to create tool execution profiles, or different instructions for how to run a tool, and switch among them.

To use the settings plugin, apply the plugin in the settings.gradle file:

apply plugin 'com.android.settings'

Centralize global configurations

To configure global configurations, use the new android block in the settings.gradle file. Here's an example:

android {
  compileSdk 31
  minSdk 28
  ...
}

Tool execution profiles

The settings plugin also lets you create execution profiles for some tools. An execution profile determines how a tool is run; you can select different execution profiles depending on the environment. In an execution profile, you can set JVM arguments for a tool and configure it to run in a separate process. Currently, only the R8 tool is supported.

Create execution profiles and set the default execution profile in the settings.gradle file, as shown in the following example:

android {
  execution {
    profiles {
      high {
        r8 {
          jvmOptions += ["-Xms2048m", "-Xmx8192m", "-XX:+HeapDumpOnOutOfMemoryError"]
          runInSeparateProcess true
        }
      }
      low {
        r8 {
          jvmOptions += ["-Xms256m", "-Xmx2048m", "-XX:+HeapDumpOnOutOfMemoryError"]
          runInSeparateProcess true
        }
      }
      ci {
        r8.runInSeparateProcess false
      }
    }
    defaultProfile "low"
  }
}

To override the default profile, select a different profile using the android.experimental.settings.executionProfile property in the gradle.properties file:

android.experimental.settings.executionProfile=high

You can also set this property using the command line, which lets you set up different workflows. For example if you have a continuous integration workflow you can use the command line to change the execution profile without having to change the settings.gradle file:

./gradlew assembleRelease \
  -Pandroid.experimental.settings.executionProfile=ci

Lint support for SDK extensions

Android Studio Flamingo provides lint support for SDK extensions. This feature allows you to update the lint tool's API check to correctly enforce API access in the presence of API backports and for new API surfaces like the Android Privacy Sandbox.

The lint tool's API check makes sure that your code only uses APIs available to you as gated by minSdkVersion or by an SDK_INT check. With SDK extensions, an API can exist in multiple SDKs. For example, an API introduced in Android U can also be added to the Android R, S, and T backport extensions. Furthermore, apps can specify multiple APIs as required using their manifest, and there are new APIs for checking whether individual extensions are available. The lint tool now handles the logic to check for overlap in what's required and what's known to be present.

Finally, there are Studio IDE features associated with API checking. This feature can now handle API violations for the new API surfaces, perform necessary checks, and register quick fixes, one per available API surface.

IntelliJ IDEA 2022.2 platform update

Android Studio Flamingo Canary 1 includes the IntelliJ IDEA 2022.2 updates, which improve the IDE experience. For details on the changes, see the IntelliJ IDEA 2022.2 release notes.

Android Studio bundled with JDK 17

Starting from Android Studio Flamingo Canary 3, the Studio IDE is bundled with JDK 17. If Android Studio is configured to use the embedded JDK, new projects will use the latest stable version of the Android Gradle plugin and JDK 17. However, existing projects might break, and you might have to manually set the JDK to a compatible version.

To learn more, see Set the JDK version.

JDK 17 required to run AGP 8.0

When using Android Gradle Plugin 8.0 to build your app, JDK 17 is now required to run Gradle. Android Studio Flamingo bundles JDK 17 and configures Gradle to use it by default, which means that most Android Studio users don't need to make any configuration changes to their projects.

If you need to manually set the JDK version used by AGP inside of Android Studio, you need to use JDK 17 or higher.

When using AGP independent of Android Studio, upgrade the JDK version by setting the JAVA_HOME environment variable or the -Dorg.gradle.java.home command-line option to your installation directory of JDK 17.

Android Studio Giraffe | 2022.3.1

The following are new features in Android Studio Giraffe.

Use Live Edit to update composables in real time

Live Edit lets you update composables in emulators and physical devices in real time. Edit composables and see the UI changes on the running device without re-deploying your app. This functionality minimizes context switches between writing and building your app, letting you focus on writing code longer without interruption. To try Live Edit, use AGP 8.1 or higher and Compose 1.3.0 or higher.

To learn more, see the Live Edit documentation.

New UI preview

Android Studio Giraffe Canary 2 introduces support for the new UI theme from IntelliJ. To opt in to this option, go to Android Studio > Settings > Appearance & Behavior.

The redesigned theme aims to reduce visual complexity, provide easier access to essential features, and disclose complex functionality as needed—resulting in a modern, cleaner look and feel. The key changes are:

• Simplified main toolbar with new VCS, Project, and Run widgets
• Tool windows have a new layout
• New Light and Dark color themes with improved contrast and consistent color palettes
• New icon set for improved legibility

For a full list of changes, see the IntelliJ new UI documentation.

The following are some known issues in Android Studio that will be addressed in upcoming releases.

• Window header toolbar is missing device picker and Android actions, for example Build, Apply Changes, and Sync Project.
• Android tool windows are not shown by default on the sidebars.
• The style of Android icons and illustrations needs to be updated.
• Duplicate controls for switching among the Code, Split, and Design modes.

If you'd like to provide feedback on the new UI in Android Studio, please file a bug.

Support for Grammatical Inflection API

Android Studio Giraffe Canary 7 introduces support for the Grammatical Inflection API (available as of Android 14 Developer Preview 1).

This new feature lets you personalize the UI for your users by adding translations inflected based on your user's grammatical gender when required. You can add grammatically masculine, feminine, or neutral translations. When no grammatically inflected translation is provided for a string, Android displays the default translation for the language.

Automatic per-app language support

Starting with Android Studio Giraffe Canary 7 and AGP 8.1.0-alpha07, you can configure your app to support per-app language preferences automatically. Based on your project resources, the Android Gradle plugin generates the LocaleConfig file and adds a reference to it in the final manifest file, so you no longer have to do it manually. AGP uses the resources in the res folders of your app modules and any library module dependencies to determine the locales to include in the LocaleConfig file.

Note that the automatic per-app language feature supports apps that run Android 13 (API level 33) or higher. To use the feature, you must set minSdkVersion to 33 or higher. To configure per-app language preferences for prior versions of Android, you still need to use the APIs and in-app language pickers.

To enable automatic per-app language support, specify a default locale:

1. In the app module's res folder, create a new file called resources.properties.

2. In the resource.properties file, set the default locale with the unqualifiedResLocale label. To form the locale names, combine the language code with the optional script and region codes, separating each with a dash:

   • Language: Use the two- or three-letter ISO 639-1 code.
   • Script (optional): Use the ISO 15924code.
   • Region (optional): Use either the two-letter ISO 3166-1-alpha-2 code or three-digit UN_M.49 code.

   For example if your default locale is American English:

       unqualifiedResLocale=en-US
       

AGP adds this default locale and any alternative locales you've specified, using values-* directories in the res folder, to the auto-generated LocaleConfig file.

Automatic per-app language support is off by default. To turn the feature on, use the generateLocaleConfig setting in the androidResources {} block of the module-level build.gradle.kts file (build.gradle file if you're using Groovy):

android {
  androidResources {
    generateLocaleConfig = true
  }
}

android {
  androidResources {
    generateLocaleConfig true
  }
}

New API support for Compose Animation Preview

Compose Animation Preview now also supports animate*AsState, CrossFade, rememberInfiniteTransition, and AnimatedContent (in addition to updateTransition and AnimatedVisibility). To use these additional APIs with Compose Animation Preview, upgrade to Android Studio Giraffe Canary 3 and Compose 1.4.0-alpha04 or higher.

Compose Animation Preview also has new pickers that let you set non-enum or boolean states to debug your Compose animation using precise inputs. For all supported Compose Animation APIs, you can play, pause, scrub, control speed, and coordinate.

Device mirroring

Minimize the number of interruptions when developing by streaming your device display directly to Android Studio. Device mirroring gives you the ability to interact with a physical device using the Running Devices window in Studio. To enable this feature, go to File > Settings > Tools > Device Mirroring and check the box next to Enable mirroring of physical Android devices. Once enabled, connect your device and either deploy your app or open the Running Devices window to begin streaming the device's display and interacting with it from the IDE.

To learn more, see the Android Studio Electric Eel release note.

View and manage processes in the Device Explorer

Android Studio Giraffe includes an updated Device Explorer, known as the Device File Explorer in previous versions of Android Studio. In the Device Explorer, files and related actions are located in the Files tab. In the new Processes tab, view a list of debuggable processes for the connected device. From there you can also select a process and perform a kill , force-stop , or attach the debugger to a given process .

To learn more, see View on-device files with Device File Explorer.

Use Firebase Test Lab devices with Gradle Managed Devices

You can now run your automated instrumented tests at scale on Firebase Test Lab devices when using Gradle Managed Devices. Test Lab lets you run your tests simultaneously on a wide range of Android devices, both physical and virtual. These tests run in remote Google data centers. With support from Gradle Managed Devices, the build system can now fully manage running tests against these Test Lab devices based on the configurations in your project's Gradle files.

Get started with Gradle managed Firebase Test Lab devices

The following steps describe how to start using Firebase Test Lab devices with Gradle Managed Devices. Note that these steps use the gcloud CLI to provide user credentials, which might not apply to all development environments. For more information on what authentication process to use for your needs, see How Application Default Credentials works.

1. To create a Firebase project, go to the Firebase console. Click Add project and follow the on-screen prompts to create a project. Remember your project ID.

2. To install the Google Cloud CLI, follow the steps at Install the gcloud CLI.

3. Configure your local environment.

   1. Link to your Firebase project in gcloud:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. Authorize the use of your user credentials for API access:

      gcloud auth application-default login
      

   3. Optional: Add your Firebase project as the quota project. This step is only needed if you exceed the no-cost quota for Test Lab.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      

4. Enable required APIs.

   In the Google Developers Console API Library page, enable the Cloud Testing API and Cloud Tool Results API by typing these API names into the search box at the top of the console, and then clicking Enable API on the overview page for each API.

5. Configure your Android project.

   1. Add the Firebase Test Lab plugin in the top-level build.gradle file:

      plugins {
        ...
        id 'com.google.firebase.testlab' version '0.0.1-alpha01' apply false
      }
      

   2. Enable custom device types in the gradle.properties file:

      android.experimental.testOptions.managedDevices.customDevice=true
      

   3. Add the Firebase Test Lab plugin in the module-level build.gradle file:

      plugins {
        ...
        id 'com.google.firebase.testlab'
      }
      

Create and run tests on a Gradle managed Firebase Test Lab device

You can specify a Firebase Test Lab device for Gradle to use for testing your app in the module-level build.gradle file. The following code sample creates a Pixel 2 running API level 30 as a Gradle managed Test Lab device called device1.

android {
    testOptions {
        managedDevices {
            devices {
                device1 (com.google.firebase.testlab.gradle.ManagedDevice) {
                    device = "Pixel2"
                    apiLevel = 30
                }
            }
        }
    }
}

To run your tests using the Gradle managed Test Lab devices you configured, use the following command. device-name is the name of the device you configured in your Gradle build script, such as device1, and BuildVariant is the build variant of your app you want to test. Note that Gradle doesn't run tests in parallel or support other Google Cloud CLI configurations for Test Lab devices.

On Windows:

gradlew device-nameBuildVariantAndroidTest

On Linux or macOS:

./gradlew device-nameBuildVariantAndroidTest

The test output includes a path to an HTML file that has the test report. You can also import test results into Android Studio for further analysis by clicking Run > Test History in the IDE.

New Android SDK Upgrade Assistant

Android Studio Giraffe introduces the Android SDK Upgrade Assistant, a new tool that helps you upgrade the targetSdkVersion, or the API level that your app targets. The Android SDK Upgrade Assistant guides you through upgrading targetSdkVersion level by level. For each migration step, it highlights the major breaking changes and how to address them.

To open the Android SDK Upgrade Assistant, go to Tools > Android SDK Upgrade Assistant. In the Assistant panel, select the API level that you want to upgrade to for guidance. For the best experience, you should upgrade targetSdkVersion values one level at a time.

The Android SDK Upgrade Assistant includes only the major changes you need to be aware of in each API level. For more comprehensive lists of changes, see the Android release summaries.

This feature is under active development. If you have any feedback, please file a bug.

Support for Gradle Version Catalogs

Android Studio Giraffe introduces support for Gradle Version Catalogs, a feature that lets you manage dependencies in one central location and share dependencies across modules or projects. Android Studio now makes it easier to configure version catalogs through editor suggestions and integration with the Project Structure dialog. To learn how to update to Gradle Version Catalogs, see Migrate your build to version catalogs.

Code completion and navigation

Android Studio offers code completion when you're editing a version catalog in the TOML file format or adding a dependency from a version catalog to a build file. To use code completion, press Ctrl+Space (Command+Space on macOS). In addition, quickly navigate from a dependency reference in your app's build.gradle file to where it's declared in the version catalog by pressing Ctrl+b (Command+b on macOS).

Integration with the Project Structure dialog

If your project uses a version catalog defined in the TOML file format, you can edit variables you've defined there through the Project Structure dialog Variables view (File > Project Structure > Variables) in Android Studio. For each version catalog, there is a drop-down that lists the variables from that catalog. To edit a variable, click on its value and overwrite it. When you save these changes, the TOML file is updated accordingly.

You can also update dependencies in the Project Structure dialog Dependencies view (File > Project Structure > Dependencies). To update versions using the Project Structure dialog, navigate to the module and dependency you want to edit, and then update the Requested Version field. When you save these changes, the TOML file is updated accordingly. Note that if the dependency version was defined using a variable, updating the version directly this way replaces the variable with a hardcoded value. Also be aware that removing a dependency from a build file, whether you use the Project Structure dialog or not, doesn't remove the dependency from the version catalog.

Known issues and limitations

The following are known issues or limitations with Gradle Version Catalogs support in Android Studio.

Error highlighting plugin alias declarations in Kotlin script files

When you add a plugin declaration of the form alias(libs.plugins.example), the editor adds a red underline under the libs part. This is a known issue in Gradle versions 8.0 and lower and will be resolved in a future release of Gradle.

Android Studio support only for version catalogs in TOML format

Currently the Android Studio code completion, navigation, and Project Structure dialog support is only available for version catalogs defined in the TOML file format. However, you can still add a version catalog directly in the settings.gradle file and use its dependencies in your project.

Can't add dependencies to version catalog through Project Structure dialog

If your project uses version catalogs and you add dependencies through the Project Structure dialog, they're added to the build.gradle file instead of the catalog. This issue will be addressed in a future release.

Navigation for KTS build files not supported

Navigating to a dependency definition in a version catalog by using Control+click (Command+click on macOS) isn't yet supported for build files written using Kotlin script.

"Find usages" functionality not supported

Finding usages of a version catalog variable in other build files isn't yet supported, whether the build file is in KTS or Groovy. That is, using Control+click (Command+click on macOS) on a variable definition in a version catalog doesn't lead to the build files where the variable is used.

Project Structure dialog doesn't show catalogs from composite builds

The Project Structure dialog in Android Studio shows multiple catalog files if they're in the root gradle folder, but doesn't show catalogs for a composite build. For example if you have two catalog files, one for your app and one for a composite build, the Project Structure dialog only shows the app catalog file. You can use a composite build, but you have to edit its TOML file directly.

Enhanced diagnostic tools and bug reporting

Android Studio Giraffe Canary 8 introduces new diagnostic tools that make it easier to report bugs with relevant log files attached. To use the new diagnostic report generator, follow these steps:

1. To launch the tool, click Help > Collect Logs and Diagnostic Data. A dialog appears that lets you choose which files to include.
2. Check or un-check specific files to include in your diagnostic report. Click on a specific file in the menu to see a preview of it.
3. When you're ready to export the diagnostic report, agree to the terms and click Create.
4. Select the location where you want to save the diagnostic report zip file and click Save.

As part of this enhancement, the bug reporting template (Help > Submit feedback) has also been updated to emphasize the importance of attaching log files. If you file a bug, be sure to attach logs because they help us isolate the issue and are an essential first step to our debugging process.

Make selected modules toolbar button

Starting with Android Studio Giraffe Canary 10, build only the current module you're working on by selecting the Make Selected Modules build option in the toolbar. This new option lets you check that the code you just wrote compiles without building more than needed. Alternatively, build your entire project by clicking the arrow next to the build button and selecting Make Project.

Whichever option you selected last (Make Selected Modules or Make Project) stays on the button until it's changed using the arrow. The Make Selected Modules option does the same thing as the action available under Build > Make Selected Modules.

Download info during sync

The Sync tool window now includes a summary of time spent downloading dependencies and a detailed view of downloads per repository. This view updates live as sync takes place. You can use this information to determine whether unexpected dependency downloads are negatively impacting your sync performance. Since Gradle resolves dependencies by searching through each repository in the declared order, it's important to list the repository that hosts most dependencies at the top of the repository configuration list. Additionally, if you see a high number of failed requests for a specific repository, it could indicate that the repository should be removed or moved lower in your repository configuration.

This download info is also available during builds in the Build tool window and Build Analyzer.

Android Lint contains bytecode targeting JVM 17

Starting with AGP 8.1.0-alpha04, Android Lint contains bytecode targeting JVM 17. If you write custom lint checks, you need to compile with JDK 17 or higher and specify jvmTarget = '17' in your Kotlin compiler options.

To learn more about the lint tool, see Improve your code with lint checks.

Disable build optimization for target API level only

Starting with Android Studio Giraffe Canary 6, you can disable IDE optimization for the target device API level. By default, Android Studio reduces overall build time by tailoring the dexing process for the API level of the target device you're deploying to. To turn this feature off, go to File > Settings > Experimental (Android Studio > Settings > Experimental on macOS) and uncheck Optimize build for target device API level only. Note that turning off this build optimization might increase build time.

Native library compression setting moved to DSL

Starting with AGP 8.1.0-alpha10, you'll get a warning if you don't configure native library compression using the DSL instead of the manifest. The following guidance explains how to update your configuration to use the DSL. To get help making these updates, use the AGP Upgrade Assistant (Tools > AGP Upgrade Assistant).

To use uncompressed native libraries, remove the android::extractNativeLibs attribute from the manifest and add the following code to the module-level build.gradle.kts file (build.gradle file if you're using Groovy):

android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging = false
    }
  }
}

android {
  packagingOptions {
    jniLibs {
      useLegacyPackaging false
    }
  }
}