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 | 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.
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.
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.
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.
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:
In the Device Manager, press the "overflow" dropdown menu icon of one of the devices you want to pair and select Pair Wearable.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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.
Switch between view presets
Logcat now allows you to quickly .switch between different view
modes—Standard, Compact, and Custom—by clicking
.
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.
New key-value search
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.
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
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
at the end of the query field..
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:
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:
|
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:
|
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.
|
| 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:
|
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 debugging Kotlin Coroutines
Android Studio Dolphin now adds support for debugging Kotlin coroutines in your Android projects. The supported functionality is similar to what is currently available in IntelliJ IDEA 2021.3, but is now also available in Android Studio.
Before you get started, ensure that your app projects uses kotlinx-coroutine-core
version 1.6.0
or higher. Then, debug your app as you normally would on a device running API
level 29 or higher.
When setting a breakpoint in a suspend function, make sure the breakpoint sets
Suspend to All.
When your app hits the breakpoint, you can see coroutines and their states
grouped by dispatcher in the Coroutines tab. You can use the Variables
tab as you normally would, so that you can investigate values of local variables
and fields available in a coroutine at each breakpoint.
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).
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
}
}
}
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 see the effect of updates to composables in real time. Live Edit updates Compose Preview and deploys code changes to an emulator or device. You don't have to wait for builds or deployments to be completed, so you can make faster progress in the creation of your app’s experience.
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.
- 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.
- 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.
- The Issues panel shows the top events that Crashlytics has data for, and is sorted by your most impactful crashes.
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.
- 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.
- Use the severity filters to select or deselect events that are Fatal
or Non-Fatal
.
- 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.
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.
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.
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.