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.

Version	Channel
Android Studio Dolphin | 2021.3.1	Stable
Android Gradle plugin 7.3.1	Stable
Android Studio Electric Eel | 2022.1.1	Beta
Android Studio Flamingo | 2022.2.1	Canary

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 Electric Eel | 2022.1.1

The following are new features in Android Studio Electric Eel.

Live Edit

In Android Studio Electric Eel, you can use Live Edit to deploy code changes to your composable to an emulator or device in real time. You don't have to wait for builds or deployments to be completed, so you can make faster progress in creating your app.

Live Edit is available in the Electric Eel Canary channel as an experimental feature. To turn it on manually, navigate to File > Settings > Editor > Live Edit (Android Studio > Preferences > Editor > Live Edit on a Mac).

Live Edit focuses on UI- and UX-related code changes. Live Edit doesn't currently support changes such as method signature updates, adding new methods, or class hierarchy changes. Live Edit is an experimental feature in active development, so you might experience some unstable behavior. If you find an issue, please let us know so we can work to fix it. You can also see a list of open issues here. For more information, see Live Edit in Android Studio.

SDK insights

View dependency insights from the new Google Play SDK Index, a public portal with information about popular dependencies, or SDKs. If a specific version of a library has been marked as outdated by its author, a corresponding Lint warning appears when viewing that dependency definition. This enables you to discover and update dependency issues during development instead of later when you go to publish your app on the Play Console. You can learn more about this new tool on the Android Developer's Blog post here.

App Quality Insights from Firebase Crashlytics

Starting with Android Studio Electric Eel, you can see and act on app crash data from Firebase Crashlytics directly in the IDE. This integration pulls stack trace data and crash statistics from Crashlytics into the new App Quality Insights tool window in the IDE, so you don't have to jump back and forth between your browser and the IDE. Development teams can benefit from key capabilities including the following:

• See lines in your code highlighted when they have related Crashlytics event data.
• See the stack trace for top crashes and click on the stack trace to jump to the relevant lines in your code.
• See summary statistics about top crash and non-fatal events, for example grouped by device manufacturer and Android version.
• Filter events by severity, time, and app version.
• Get a browser link that opens the Crashlytics dashboard page with more details about the event.

With the Android Studio and Crashlytics integration, you can write code and address top crash issues all in the same spot. This enriched development experience helps you stay informed about your app's performance and minimize disruptions for your users. If you encounter any issues with this feature, file a bug.

If you're not using Crashlytics yet and would like to learn more about its offerings, see Firebase Crashlytics.

Get started

To see Crashlytics data in Android Studio, you need to set up Firebase and Crashlytics in your app project. Here's how: open the Firebase Assistant in Android Studio by going to Tools > Firebase, click Crashlytics, and then follow the tutorial to add Firebase and Crashlytics to your project. You can read more about the Firebase Assistant workflow in Firebase's getting started guide for Android.

If you've already added Firebase and Crashlytics to your app, sign in to your Developer account in the IDE by clicking on the avatar icon . After you sign in, click on the App Quality Insights tool window. You should see the Issues, Sample Stack Trace, and Details panels populate with reports from Crashlytics.

Navigate Crashlytics data in Android Studio

The App Quality Insights tool window has rich data that gives you insight into the events your users are encountering, and links to help you quickly navigate to the sources of those events.

1. If your project includes multiple app modules, make sure the module you want to see event data for is selected from the module dropdown menu.
2. Use the application ID dropdown menu to select the app ID you want to analyze. For example, while you might work on the debug version of your app in the IDE, you might want to see event data for your production version of your app that your users install.
3. The Issues panel shows the top events that Crashlytics has data for, and is sorted by your most impactful crashes.

4. The Sample Stack Trace panel shows details about the latest occurrence of the event you click on in the Issues panel. You can see the event's stack trace and click on the stack trace to jump to the relevant lines in your code base.

   There is also information about the device type affected, its Android version, and the time the event occurred, as well a link to the event in the Firebase Crashlytics dashboard. The dashboard is useful if you want to dive deeper and inspect additional stack traces, trends, and custom logs.

5. The Details panel breaks down the crash counts by device type and Android version, so you can determine which user groups are most affected. It also shows which app version(s) experienced the crash and the number of users affected.
6. Use the severity filters to select or deselect events that are Fatal or Non-Fatal .
7. Use the time range and app version filters to hone in on certain subsets of events.

In addition to being able to navigate from stack trace to code, you can also jump from code to stack trace: Android Studio now highlights lines of code that are related to crashes so you can easily spot and debug them.

When you hover over a highlighted line of code, a pop-up appears that shows the event involved, its frequency, and the number of devices affected. You can click on Open in App Quality Insights to jump to the event details in the App Quality Insights tool window.

Resizable emulator

You can now test your app on multiple screen sizes and with a single resizable emulator. Testing on a single resizable emulator not only allows you to rapidly test changes across different interfaces, but also promotes a smoother development experience by saving the compute resources and memory that would be required to maintain separate virtual devices.

To use the resizable emulator, you need Android Emulator version 31.1.3 or higher (you can upgrade versions by going to Tools > SDK Manager). To create a resizable Android Virtual Device (AVD), in the Create device flow, select the “Resizable (Experimental)” phone hardware profile, download the Android Tiramisu system image, and follow the prompts to create the AVD.

When you deploy your app to the resizable emulator, you can use the Display Mode dropdown menu in the emulator toolbar to quickly toggle between a set of common device types. The emulator screen will resize so you can easily test your app across a range of screen sizes and densities.

Emulated Bluetooth

You can now discover and connect two phone emulators using virtual Bluetooth. With virtual Bluetooth, you can test that your app can recognize and gain access to the Bluetooth adapter in a scalable way. This feature is available on Android Emulator 31.3.8 and higher with system image T (API 33). We plan to add more support for creating sample virtual peripherals, such as beacons and heart rate monitors, and integration testing for your Bluetooth features in the future.

Device Mirroring

You can now mirror your device in the Running Devices window in Android Studio Electric Eel. By streaming your device's display directly to Android Studio, you can execute common actions such rotating the screen, changing the volume, or locking/unlocking the device right from the IDE itself.

Device Mirroring is available in the Electric Eel Canary channel as an experimental feature. To turn it on manually, navigate to File > Settings > Experimental (Android Studio > Preferences > Experimental on a Mac), and check the box next to Device Mirroring.

To get started, ensure you are connected to a device. All devices that you are connected to are mirrored in tabs in the Running Devices window, which you can open by navigating to View > Tool Windows > Running Devices. When you deploy an app or test to a connected device, the Running Devices window appears automatically and shows the mirrored device.

Privacy notice

If device mirroring is enabled, Android Studio automatically starts device mirroring for any connected and paired device. This might result in information disclosure for devices connected with the adb tcpip command because the mirroring information and commands are passed over a non-encrypted channel. In addition, Android Studio uses a non-encrypted channel to communicate with the adb server, so mirroring information can be intercepted by other users on your host machine.

Updates to Logcat

In Android Studio Electric Eel, the new version of Logcat is enabled by default to make it easier to parse, query, and keep track of logs. This represents the most significant update to the tool since its introduction, and we welcome you to provide feedback.

Android Gradle plugin targets JVM 11 bytecode

Starting with Android Gradle plugin 7.4.0-alpha04, AGP ships wth JVM 11 bytecode. This means that if you compile against AGP, or write custom Lint checks, you need to start targeting JVM 11 bytecode. One of the ways to do this is to include the following in your module-level build.gradle file:

sourceCompatibility = "11"
targetCompatibility = "11"

AGP Upgrade Assistant post-upgrade report and rollback functionality

The AGP Upgrade Assistant now includes a post-upgrade report. This report describes the steps that were completed and if the upgrade was successful or unsuccessful. It also includes an action to revert changes that were made by the upgrade assistant, if there are issues building or testing the project after the upgrade.

Project import runs in parallel

Starting with Android Studio Electric Eel Canary 6, the IDE imports projects in parallel when you use Gradle 7.4.2 or higher and Android Gradle plugin 7.2.0 or higher. Specifically, when Android Studio triggers a Gradle sync, the information that describes projects included in your build is created in parallel. This should result in faster sync times, especially for larger projects. Benchmarks show that the time it takes to build Gradle models for a very large project (with 3,500 Gradle subprojects) is reduced by 50%, from 10 to 5 minutes.

Desktop Android Virtual Device now available

You can now test how your app works on desktop devices such as Chromebooks by using a Desktop Android Virtual Device (AVD). Users often interact with apps differently on large screen devices, and the Desktop AVD enables you to see how your app behaves in this environment. Here are some of the unique functionalities you can test:

• App resizing: resize your app by dragging the window edges.
• Freeform window management: place your app in various places on the desktop screen, and minimize, maximize, and restore the app window.
• Notifications: check that the notifications render correctly when pulled up from the system tray on the desktop.

To learn more about Desktop AVDs and how to incorporate them in your testing workflow, see Desktop AVD in Android Studio on the ChromeOS developers blog.

Check download impact using Build Analyzer

Starting with Android Studio Electric Eel Canary 10, Build Analyzer provides a summary of time spent downloading dependencies and a detailed view of downloads per repository. You can use this information to determine whether unexpected dependency downloads are negatively impacting your build performance. This is especially important during incremental builds, which shouldn't consistently download artifacts.

Specifically, you can use this information to identify configuration issues, such as use of dynamic versions of dependencies that cause unexpected downloads. Also, 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.

Layout Inspector recomposition rendering highlights

In Android Studio Electric Eel, your recompositions are highlighted to help you determine where in the UI your composables are recomposing. The highlighted portion shows a gradient overlay of the composable in the image section of the Layout Inspector, and gradually disappears so that you can get an idea of where in the UI the composable with the highest recompositions can be found. If one composable is recomposing at a higher rate than another composable, then the first composable receives a stronger gradient overlay color.

Use Compose Preview with different devices

In Android Studio Electric Eel, you can edit the device parameter of the Preview annotation to define configurations for your Composables in different devices.

Autocompletion

When the device parameter has an empty string (@Preview(device = “”)), you can invoke autocomplete by pressing Ctrl + Space. You should be able to set the values of each parameter. To switch, press Enter, or cancel with Esc.

Inspection

If you set an invalid value, the declaration is underlined in red and a fix may be available (Alt + Enter (⌥ + ⏎ for macOS) > Replace with …. The Inspection will try to provide a fix that is closest to resembling your input.

Preview Picker

You can use the Preview Picker to edit your configurations. To get started, click the settings icon next to your Preview.

Universal Problems panel

In Android Studio Electric Eel, you can view all the issues for your Design Tools in a shared issue panel. To view the tool window, navigate to View > Tool Windows > Problems.

Visual linting

Starting with Electric Eel Canary 1, Android Studio automatically runs your layout to check for Visual Lint issues across different screen sizes. When you open Layout Validation, you can see all your layouts render in multiple device sizes. If there's an an issue, you can see it in the Problems panel, which is designed to show all issues within design tools, regardless of if your layout is written in Views or Compose.

Compose Preview

Starting with Android Studio Electric Eel Beta 1, you can see immediate updates to your Preview changes as you make them.

Android Studio Flamingo | 2022.2.1

The following are new features in Android Studio Flamingo.

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.

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.

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.

Default value for RenderScript flag changed

Starting with AGP 8.0.0-alpha02, the default value for the buildFeatures.renderScript flag has changed from true to false. If you need to enable RenderScript compilation, set the flag explicitly to true. This build feature should be enabled only in the modules that use it.

To get help adjusting your code to support this change, use the AGP Upgrade Assistant.

Breaking change: namespace required in module-level build.gradle file

Starting with AGP 8.0.0-alpha03, 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.

To get help moving to the new namespace DSL, use the AGP Upgrade Assistant (Tools > AGP Upgrade Assistant).

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.

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.

Default value for AIDL flag changed

Starting with AGP 8.0.0-alpha04, the default value for the buildFeatures.aidl flag has changed from true to false. If you need to enable this feature, make sure that it's explicitly set to true. This build feature should be enabled only in the modules that use it.

To get help adjusting your code to support this change, use the AGP Upgrade Assistant (Tools > AGP Upgrade Assistant).

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.

Use Firebase Test Lab devices with Gradle Managed Devices

Starting with AGP 8.0.0-alpha05, you can 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

To start using Firebase Test Lab devices with Gradle Managed Devices, follow these steps:

1. To create a Firebase project, go to the Firebase console and click Add project. Follow the prompts and give your project a name.
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-name
      

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

      gcloud auth application-default login
      

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

      gcloud auth application-default set-quota-project firebase-project-name
      

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 Canary 6 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.

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.

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.

Starting with Android Studio Flamingo Canary 6, Live Edit is turned on by default. To turn this feature off, go to File > Settings from the menu bar (or Android Studio > Preferences on macOS), click on Editor > Live Edit, and check the None box.

Support for Gradle Version Catalogs

Android Studio Flamingo Canary 7 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. If you're new to Gradle Version Catalogs, see its documentation first to get started.

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. In addition, you can quickly navigate from a dependency reference in your app's build.gradle file to where it's declared in the version catalog by clicking on it while pressing Ctrl (Command 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 should be updated accordingly.

You can also update dependencies in the Project Structure dialog Dependencies view (File > Project Structure > Dependencies). To update versions, 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 should be 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.

Known issues and limitations

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

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 KTSA build files not supported

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

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.

Default value for BuildConfig flag changed

Starting with AGP 8.0.0-alpha09, the default value for the buildFeatures.buildConfig flag has changed from true to false. If you need to enable this feature, make sure that it's explicitly set to true. This build feature should be enabled only in the modules that use it.

To get help adjusting your code to support this change, use the AGP Upgrade Assistant (Tools > AGP Upgrade Assistant).