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 Chipmunk | 2021.2.1 Stable
Android Gradle plugin 7.2.0 Stable
Android Studio Dolphin | 2021.3.1 Beta
Android Studio Electric Eel | 2022.1.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 Dolphin | 2021.3.1

The following are new features in Android Studio Dolphin.

New in Compose

The following are new features and improvements to Jetpack Compose in Android Studio.

Compose Animation Coordination

If your animations are described in a composable preview, you can now use Animation Preview to inspect and coordinate all of them at once. You can also freeze a specific animation.

Gif showing inspection with All Animations UI

Compose Multipreview Annotations

You can now define an annotation class that includes multiple Preview definitions and use that new annotation to generate those previews at once. Use this new annotation to preview multiple devices, fonts, and themes at the same time—without repeating those definitions for every single composable.

Multipreview annotations UI

Compose Recomposition Counts in Layout Inspector

When debugging your Compose layouts, knowing when composables do or do not recompose is important in understanding whether your UI is implemented properly. For example, if it's recomposing too many times, your app might be doing more work than is necessary. On the other hand, components that do not recompose when you expect them to can lead to unexpected behaviors.

The Layout Inspector now allows you to see when discrete composables in your layout hierarchy have either recomposed or skipped. This information is shown live, while you interact with your app. To get started, make sure your app is using Compose 1.2.0-alpha03 or higher. Then deploy your app as you normally would.

New composition and skip counter in Layout Inspector

Open the Layout Inspector window and connect to your app process. In the Component Tree, you should see two new columns appear next to the layout hierarchy. The first column show the number of compositions for each node and the second columns displays the number of skips for each node. You can also see similar information in the Attributes pane when you select a composable from the Component Tree or the Layout Display.

If you want to reset the count, click Reset near the top of the Component Tree panel. Resetting the count can help you understand recompositions or skips during a specific interaction with your app.

Enable the composition and skip counter in Layout Inspector

Updated Wear OS emulator pairing assistant

Starting with Android Studio Dolphin Canary 3, the Wear OS emulator pairing assistant has improved features that make it easier to manage and connect Wear emulators. You can now do the following:

  • See Wear devices in the Device Manager.
  • Pair multiple Wear devices with a single virtual or physical phone.
  • Automatically reconnect previously paired devices when they’re launched. Android Studio now remembers and re-pairs the last pair set up.

To use these new features, make sure your phone emulators are API level 30 or higher and have the Google Play Store installed. Also, make sure your Wear emulators are API level 28 or higher. To upgrade to the latest system images for your emulated devices, go to Tools > SDK Manager.

Get started

Wear devices are now visible in the Device Manager. To pair two existing devices, follow these steps:

  1. In the Device Manager, press the "overflow" dropdown menu icon of one of the devices you want to pair and select Pair Wearable.

    Pair a wearable in the Device Manager

  2. This should launch the Wear OS emulator pairing assistant. If you clicked Pair Wearable on a phone, you should see a list of available Wear devices. If you started with a Wear device, you should see a list of available phones. Select the device you want to pair, and click Next.
  3. It might take a few minutes for Android Studio to launch and prepare the devices. If your phone doesn't have the Wear OS companion app installed already, follow the prompts to login to the Play Store, install it, and set it up.
  4. To pair your devices, in the Wear OS app on your phone, click the three dot menu and select Pair with emulator.

After your devices have been successfully paired, the Device Manager should show small icons next to the paired devices. You can also click on the overflow dropdown menu and select View Details to see a list of paired devices.

View paired devices in the Device Manager

You can have multiple phone and Wear device pairings at once. For example, you can have Phone A paired with Wear A and simultaneously a second Phone B Paired with a different Wear B. A Wear device can only be paired with one phone at a time, though.

Connect a phone to multiple Wear devices

To connect a second Wear device to a virtual or physical phone, follow the same steps you would for an initial pairing: locate the phone or Wear device you want to pair in the Device Manager, click on the overflow dropdown menu, and click Pair Wearable. Follow the pairing assistant guidance, described in the previous section, to pair the devices.

Automatically reconnect paired devices

Android Studio now remembers your last pairings, so you don't have to manually pair them as often. If you close one or both of your paired devices and re-launch them, or if you close and reopen Android Studio, the devices should reconnect automatically.

Updated Wear OS emulator toolbar

Starting with Android Studio Dolphin Canary 2, for Wear emulators with API level 28 or higher, the emulator toolbar now has buttons that simulate the physical buttons and common actions on the device. The new buttons are: Button 1 and Button 2 (Button 2 is only available on API level 30 or higher), the Palm button, and the Tilt button. Here are some of the actions you can do using the new buttons on your Wear emulator:

  • To set your device to ambient mode, click the Palm button.
  • To return your device to the last screen it was on before ambient mode, click the Tilt button.

Wear emulator with Wear-specific buttons

New Wear OS run configurations

New run configurations have been added to quickly run and debug surfaces specific to Wear OS like watch faces, Tiles, and complications.

You can create these new configurations from the Run/Debug Configurations dialog when running your application.

WearOS new launch configurations

Alternatively, you can also run these surfaces from the gutter icon that is located next to the declaration of the surface, as shown in the following image.

WearOS new launch configurations

New Logcat

Logcat has been updated to make it easier to parse, query, and track logs. We are working to improve this feature and look forward to your feedback.

New formatter

Logcat now formats logs to make it easier to scan useful information, such as tags and messages, and identify different types of logs, such as warnings and errors.

New formatting for logs in Logcat

Create multiple Logcat windows

You can now create multiple tabs within Logcat, so that you can easily switch between different devices or queries. Right-clicking a tab allows you to rename it, and you can click and drag to rearrange the tabs.

Additionally, to help you more easily compare between two sets of logs, you can now split the view within a tab by right-clicking in the log view and selecting either Split Right or Split Down. To close a split, right-click and select Close. Each split allows you to set its own device connection, view options, and query.

Create multiple logcat windows using splits

Switch between view presets

Logcat now allows you to quickly .switch between different view modes—Standard, Compact, and Custom—by clicking View mode selector. Each view mode provides a different default setting for showing you more or less information, such as timestamps, tags, and process IDs (PID). You can also customize each of these default view modes, as well as a custom view mode, by selecting Modify View.

Screenshot of switching between different view modes

In the previous version of Logcat, you had the option to either use string search (with support for regular expressions) or create a new filter by populating various fields using the Logcat UI. The first option made search more complex and the second option made sharing and setting up queries more difficult. We’ve now simplified the experience by introducing key-value searches right from the main query field.

Screenshot of new query syntax with auto-complete

This new query system provides the accuracy of what you want to query, without relying on regular expressions, with the ability to recall past queries from history, and share those queries with others. Additionally, you still have the option to use RegEx and also exclude logs based on key-values. Here are some examples of how to use the new query system, but you can also simply start typing in the query field to see suggestions:

  • PIDs for the local app project: package:mine
  • Specific values:
    • package:<package-ID>
    • tag:<tag>
    • level:[VERBOSE | INFO | ASSERT |DEBUG | WARN | ERROR ]
  • Exclude a specific value by preceding the key with -:
    • -tag:<exclude-tag>
  • Use regular expressions with a given key by placing a ~ after the key:
    • tag~:<regular-expression-tag>
    • Combine with the exclude tag: -tag~:<exclude-regular-expression-tag>

You can also see a history of queries by clicking Query history selector in the query field and selecting them from the drop down. To favorite a query so that it stays at the top of the list across all your studio projects, click the Favourite query at the end of the query field..

Screenshot query history with favourites

Track logs across app crashes/restarts

The new Logcat now makes it easier to track logs from your app across app crashes and restarts, so that you don’t miss important logs across these events. When a Logcat notices that your app process has stopped and restarted you’ll see a message in the output—such as PROCESS ENDED and PROCESS STARTED—as shown below:

Screenshot of process restarts in logcat

And, restarting Logcat preserves your session configuration, such as tab splits, filters, and view options, so that you can continue your session easily. We appreciate any feedback you might have with the new Logcat, which you can report here.

Android testing

Android Studio Dolphin and AGP 7.3 introduce several new features and improvements to help you scale your automated instrumentation tests and see useful results you can use to debug issues.

Gradle Managed Virtual Devices

In order to improve consistency, performance, and reliability when using Android Virtual Devices for your automated instrumented tests, we’re introducing Gradle Managed Virtual Devices. This feature, available for API levels 27 and higher, allows you to configure virtual test devices in your project's Gradle files. The build system uses the configurations to fully manage—that is, create, deploy, and tear down—those devices when executing your automated tests.

This feature grants Gradle visibility into not only the tests you’re running, but also the devices’ lifecycle, thus improving the quality of your testing experience in the following ways:

  • Handles device-related issues in order to ensure your tests are executed
  • Utilizes emulator snapshots to improve device startup time and memory usage, and restore devices to a clean state between tests
  • Caches test results and reruns only tests that are likely to provide different results
  • Provides a consistent environment for running your tests between local and remote test runs

Additionally, Gradle Managed Devices introduce a new type of Emulator device, called Automated Test Devices (ATD), that are optimized to improve performance when running your instrumentation tests. Combined with support for Test Sharding, you can experiment with splitting your test suite across multiple ATD instances in order to reduce overall test execution time.

Get started

Make sure your project is using AGP version 7.3.0-alpha07 or higher. You can specify a virtual device that you want Gradle to use for testing your app in your module-level build.gradle file. The following code sample creates a Pixel 2 running API level 30 as a Gradle managed device.

android {
  testOptions {
    managedDevices {
      devices {
        pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
          // Whether the image must be a 64 bit image. Defaults to false,
          // in which case the managed device will use a 32 bit image.
          // Not applicable to arm64 machines.
          require64Bit = false
        }
      }
    }
  }
}

To run your tests using the Gradle managed devices you configured, use the following command. device-name is the name of the device you configured in your Gradle build script (such as pixel2api30), and BuildVariant is the build variant of your app you want to test.

gradlew device-nameBuildVariantAndroidTest
Define groups of devices

To help you scale your tests across multiple device configurations, such as different API levels and form factors, you can define multiple Gradle managed devices and add them to a named group. Gradle can then execute your tests across all the devices in the group in parallel.

The example below shows two managed devices added to a device group called phoneAndTablet.

testOptions {
  managedDevices {
    devices {
      pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
      nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
    deviceGroups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
    }
  }
}

To run your tests using the group of Gradle managed devices, use the following command.

gradlew group-nameGroupBuildVariantAndroidTest

Run tests using Automated Test Devices

Gradle Managed Devices supports a new type of Emulator device, called the Automated Test Device (ATD), which is optimized to reduce CPU and memory resources when running your instrumented tests. ATDs improve runtime performance in a few ways:

  • Remove pre-installed apps that are typically not useful for testing your app
  • Disable certain background services that are typically not useful for testing your app
  • Disable hardware rendering

Before getting started, make sure you update the Android Emulator to the latest available version. Then, specify an "-atd" image when defining a Gradle Managed Device in your build.gradle, as shown below:

android {
  testOptions {
    managedDevices {
      devices {
        pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATD currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
          // Whether the image must be a 64 bit image.
          require64Bit = false
        }
      }
    }
  }
}

Because ATD images are currently only available from the Canary channel, you need to specify -Pandroid.sdk.channel=3 when using these devices to run your tests, as shown below:

gradlew pixel2api30DebugAndroidTest -Pandroid.sdk.channel=3

You can also create device groups as you can with other Gradle Managed Devices. To further leverage the performance improvements, you can also use ATDs with Test Sharding to reduce the total test execution time of your test suite.

What's removed from ATD images?

In addition to operating in a headless mode, ATDs also optimize performance by removing or disabling apps and services that are typically not required for testing your app's code. The table below provides an overview of the components we've removed or disabled in ATD images and descriptions of why they might not be useful.

What’s removed in ATD images Why you might not need this when running automated tests
Google product apps:
  • Mail
  • Maps
  • Chrome
  • Messages
  • Play Store, and others
Your automated tests should focus on your own app's logic while assuming that other apps or the platform will function correctly.

With Espresso-Intents, you can match and validate your outgoing intents or even provide stub responses in place of actual intent responses.

Settings apps and services:
  • CarrierConfig
  • EmergencyInfo
  • OneTimeInitializer
  • PhotoTable (screensavers)
  • Provision
  • Settings app
  • StorageManager
  • Telephony APN Configuration
  • WallpaperCropper
  • WallpaperPicker
These apps present a GUI for end-users to change platform settings, set up their device, or manage device storage. This is typically outside the scope of app-level automated testing.


Note: Settings provider is still available in the ATD image.

SystemUI Your automated tests should focus on your own app's logic while assuming that other apps or the platform will function correctly.
AOSP apps and services:
  • Browser2
  • Calendar
  • Camera2
  • Contacts
  • Dialer
  • DeskClock
  • Gallery2
  • LatinIME
  • Launcher3QuickStep
  • Music
  • QuickSearchBox
  • SettingsIntelligence
These apps and services are typically outside the scope of automated tests for your app’s code.

If you encounter any issues using ATDs, or believe that it lacks apps or services you require for your tests, please report an issue.

Enable Test Sharding

Gradle Managed Devices support Test Sharding, which allows you to split your test suite across a number of identical virtual device instances, called shards, that run in parallel. Utilizing Test Sharding can help reduce overall test execution time at the cost of additional computational resources.

To set the number of shards you want to use in a given test run, set the following in your gradle.properties file:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

When running your tests using this option, Gradle Managed Devices provision the number of shards you specify for each device profile in the test run. So, for example, if you deployed your tests to a device group of three devices and set numManagedDeviceShards to two, Gradle Managed Devices will provision a total of six virtual devices for your test run.

When your tests are complete, Gradle will output test results in a .proto file for each shard used in the test run.

Support for custom C/C++ build systems

You can now create a custom C/C++ build system by making a shell script that writes build information in the Ninja build file format. To learn more about custom C/C++ build systems see Integrate custom C/C++ build systems using Ninja (experimental).

Screenshot of custom C/C++ build system

Minimum Kotlin plugin version is 1.5.20

Starting with Android Gradle plugin 7.3.0-alpha08, AGP requires Kotlin plugin version 1.5.20 or higher. To stay compatible, make sure to specify Kotlin plugin version 1.5.20 or higher in your build.gradle file:

org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.20

Archived APK generation enabled

Starting with AGP 7.3, all Android App Bundles built have Store Archival enabled by default. Archival is a new app bundle feature that in the future will allow users with low storage to effectively manage their app space, if supported by the store.

To opt out of the generation of archived APKs, modify the app-level build.gradle file as follows:

android {
  bundle {
    storeArchive {
      enable = false
    }
  }
}

Package attribute in manifest file is deprecated

Starting with AGP 7.3.0-alpha04, if you're using Gradle to build your project, you'll see a warning if you're still using the package attribute in the manifest file. To set the namespace for your app, you should use the namespace property in the module-level build.gradle file. To learn more, see Set a namespace.

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

Android platform support

Starting with AGP 7.3.0-beta05, the highest supported minimum SDK version is 33 (you can use minSdk = 33). The minimum SDK represents the minimum version of Android that your app can run on and is set in the app-level build.gradle file.

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.

Screenshot of live editing on a device

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.

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.

App Quality Insights tool window

  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.

Crash-related code highlighted in the IDE

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.

Resizable emulator Display Mode dropdown menu

Visual linting

Starting with Electric Eel Canary 1, Android Studio will automatically run 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, it will show up in the Universal Problems Panel, which is designed to show all issues within design tools, regardless of if your layout is written in Views or Compose.

Layout Validation UI

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.

Pairing devices using emulated Bluetooth

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.

Enable Device Mirroring checkbox UI

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.

Running Devices UI

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.