New features in Android Studio Preview

Android Studio 4.0 has been released to the stable channel. Download it here.

Android Studio 4.1 is currently in the Canary and Dev channels.

For the latest news on releases, including a list of notable fixes in each release, also see the Release updates.

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.

Android Studio 4.2

New removable setting for feature modules

Android Gradle plugin 4.2 uses bundletool 1.0.0, which introduces a behavior change for apps using feature modules: Any feature module specified as dist:install-time that's not explicitly marked as dist:removable will become non-removable by default. This new setting optimizes fusing of install-time modules with the base module, potentially improving app performance for some apps.

For more information on this new setting, see the documentation for the dist:removable tag in the documentation for feature module manifest.

This section provides a summary of the new features and changes in Android Studio 4.2.

Android Gradle plugin 4.2

New JVM resource compiler

A new JVM resource compiler in Android Gradle plugin 4.2 tool replaces portions of the AAPT2 resource compiler, potentially improving build performance, especially on Windows machines.

Starting with the Canary 7 release, the new JVM resource compiler is enabled by default.

v3 and v4 signing now supported

Android Gradle Plugin 4.2 now supports APK v3 and v4 signing formats. To enable one or both of these formats in your build, add the following properties to your module-level build.gradle or build.gradle.kts file:

// build.gradle.kts

android {
   ...
   signingConfigs {
      config {
          ...
          enableV3Signing(true)
          enableV4Signing(true)
      }
   }
}

// build.gradle

android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

APK v4 signing allows you to quickly deploy large APKs using the ADB Incremental APK installation in Android 11. This new flag takes care of the APK signing step in the deployment process.

Support for Jetpack Compose

Jetpack Compose toolkit provides a modern approach to building your app's UI. The toolkit also brings all of Kotlin's benefits, such as helping you to write concise and idiomatic code that's fully interoperable with Java.

For the best experience developing with Jetpack Compose, you should use the latest version of Android Studio 4.2. That's because when you use Android Studio to develop your app with Jetpack Compose, you can benefit from smart editor features, such as New Project templates and the ability to immediately preview your Compose UI.

To learn more and get started, go to the Jetpack Compose overview.

New Jetpack Compose tooling support in 4.2

Android Studio now includes additional support for previewing and testing apps that use Jetpack Compose.

Compose preview

The following parameters for @Preview methods are now available:

• showBackground: Switch on and off a background for your preview.
• backgroundColor: Set a color that is only used in the preview surface.
• uiMode: This new parameter can take any of the Configuration.UI_* constants and allows you to change the behavior of the preview to, for example, set it to Night Mode to see how the theme reacts.

Interactive preview

In this mode, you can interact with your UI components, click them, and see how the state changes. It's a quick way to get feedback on how your UI reacts and to preview the animations. To enable it, just click the interactive icon and the preview will switch modes.

To stop, click the Stop Interactive Preview in the top toolbar.

Deploy to device

Use this feature to deploy a snippet of your UI to a device. This will help to test small parts of your code in the device without having to start the full application.

Click the deploy to device icon next to the @Preview annotation or in the top of the preview and Android Studio will deploy that @Preview to your connected device or emulator.

Preview Data Sources API

The new Data Sources API allows you to generate previews from your data. If you have an existing list of data, or a list of themes, this API will allow you to inject it as a parameter to the @Preview method.

class HelloWorldProvider :
   CollectionPreviewParameterProvider<String>(
       listOf("Hello World", "Привет мир", "Olá Mundo", "Hola Mundo"))

@Preview
@Composable
fun HelloWorldPreview(
   @PreviewParameter(HelloWorldProvider::class) text: String
) {
   MaterialTheme {
       Text(text = text)
   }
}

To enable the above features, your module's build.gradle must contain the following settings:

  android {
  …
  buildFeatures {
    compose true
  }
  composeOptions {
     kotlinCompilerExtensionVersion = "0.1.0-dev13"
     kotlinCompilerVersion = "1.3.70-dev-withExperimentalGoogleExtensions-20200424"
   }
}

Known issues for Compose preview

androidx.ui.foundation.Dialog is currently not supported in Compose preview.

Improved instrumentation testing

Starting in Android Studio 4.2 Canary 1, instrumentation tests can now be run across multiple devices in parallel and investigated using a specialized instrumentation test results panel. Using this panel, you can determine if tests are failing due to API level or hardware properties.

Testing your app across a wide variety of API levels and form factors is one of the best ways to ensure that all users have a great experience when using your app.

To take advantage of this feature:

1. Select Modify Device Set in the target device dropdown menu (in the top-center of the IDE).

   

2. Select the target devices and click OK.

   

3. Select Multiple Devices in the target device dropdown menu and run your tests.

   

To view your test results in the Run panel, go to View > Tool Windows > Run.

The new test results panel allows you to filter your test results by status, device, and API level. Additionally, you can sort each column by clicking the header. By clicking on an individual test, you can view logs and device information individually for each device.

Apply Changes

To help you be more productive as you iterate on your app, we've made the following enhancements to Apply Changes for devices running Android 11 Developer Preview 3 or higher:

Support for additional code changes

For devices running Android 11 Developer Preview 3 or higher, you can now add static final primitive fields and then deploy those changes to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity .

You can now also add resources and then deploy those changes to your running app on Android 11 devices by clicking Apply Changes and Restart Activity .

Android Studio 4.1

This section provides a summary of the new features and changes in Android Studio 4.1.

System Trace UI: Easier selection, new analysis tab, and more frame rendering data

The System Trace UI in the Android Studio profiler includes the following improvements:

• Box selection: In the Threads section, you can now drag your mouse to perform a box selection of a rectangular area, which you can zoom into by clicking the Zoom to Selection button on the top right (or use the M keyboard shortcut). When you drag and drop similar threads next to each other, you can select across multiple threads to inspect all of them at once. For example, you may want to perform analysis on multiple worker threads.

  

• Summary tab: The new Summary tab in the Analysis panel displays:

  • Aggregate statistics for all occurrences of a specific event, such as an occurrence count and min/max duration.
  • Trace event statistics for the selected occurrence.
  • Data about thread state distribution.
  • Longest-running occurrences of the selected trace event.

  

  To navigate to another occurrence, select another row from the table.

• Display data: In the Display section, new timelines for SurfaceFlinger and VSYNC help you investigate rendering issues in your app's UI.

  

For basic usage instructions on how to record a system trace, see the Record traces section of Inspect CPU activity with CPU Profiler.

Standalone profilers now available

It's now possible to access the Android Studio Profilers in a separate window from the primary Android Studio window.

To run the standalone profilers, do the following:

1. Make sure Android Studio is not running on your system.

2. Go to the installation directory and navigate to the bin directory:

   Windows/Linux: <studio-installation-folder>/bin

   macOS: <studio-installation-folder>/Contents/bin

3. Depending on your OS, run profiler.exe or profiler.sh. The Android Studio splash screen appears.

   After the splash screen disappears, a profiler window opens:

4. Start the Android emulator or connect an Android device and wait for the home screen to load. To run the emulator from the command line, see Start the emulator from the command line. If you start the emulator from Android Studio, be sure to close Android Studio after the emulator has started.

   In the menu of the standalone profiler, click the button and all of your connected devices and emulators should now be displayed:

   

   As an example, open Google Maps in the emulator. Create a new profiling session by selecting an emulator from the dropdown, and then select com.google.android.apps.maps (...). This launches a profiling session.

   

When you interact with the map, touch events and CPU usage appear in the profiler. Click on the CPU, Memory, Network, or Energy graphs to show more details.

Click the button to end the profiling session.

Now you can use the profilers to inspect the performance characteristics of your app. For more information, see Profile your app performance.

Material Design Components: Updated themes and styles in new project templates

Android Studio templates in the Create New Project dialog now use Material Design Components (MDC) and conform to updated guidance for themes and styles by default. Updates include:

• MDC: Projects depend on com.google.android.material:material in build.gradle. Base app themes use Theme.MaterialComponents.* parents and override updated MDC color and “on” attributes.
• Color resources: Color resources in colors.xml use literal names (for example, purple_500 instead of colorPrimary).
• Theme resources: Theme resources are in themes.xml (instead of styles.xml) and use Theme.<ApplicationName> names.
• Dark theme: Base application themes use DayNight parents and are split between res/values and res/values-night.
• Theme attributes: Color resources are referenced as theme attributes (for example, ?attr/colorPrimary) in layouts and styles to avoid hard-coded colors.

IDE configuration directory changes in Canary 9

In the Canary 9 release, the locations for user configuration directories have been changed to the following:

Windows

Syntax: %APPDATA%\Google\<product><version>

Example: C:\Users\YourUserName\AppData\Roaming\Google\AndroidStudioPreview4.1

macOS

Syntax: ~/Library/Application Support/Google/<product><version>

Example: ~/Library/Application Support/Google/AndroidStudioPreview4.1

Linux

Syntax: ~/.config/Google/<product><version>

Example: ~/.config/Google/AndroidStudioPreview4.1

These new directory locations are consistent with recent updates to IntelliJ IDEA, the IDE on which Android Studio is based.

Dagger navigation support

Android Studio makes it easier to navigate between your Dagger-related code by providing new gutter actions and extending support in the Find Usages window.

• New gutter actions: For projects that use Dagger, the IDE provides gutter actions that help you navigate between your Dagger-annotated code. For example, clicking on the gutter action next to a method that consumes a given type navigates you to the provider of that type. Conversely, clicking on the gutter action navigates you to where a type is used as a dependency.

• Find Usages node: When you invoke Find Usages on a provider of a given type, the Find window now includes a Dependency consumer(s) node that lists consumers of that type. Conversely, invoking this action on a consumer of a Dagger-injected dependency, the Find window shows you the provider of that dependency.

Run the Android Emulator directly in Android Studio

You can now run the Android Emulator directly in Android Studio. Use this feature to conserve screen real estate, to navigate quickly between the emulator and the editor window using hotkeys, and to organize your IDE and emulator workflow in a single application window.

To run the emulator in Android Studio, make sure you're using Android Studio 4.1 with version 30.0.10 or higher of the Android Emulator, then follow these steps:

1. Click File > Settings > Tools > Emulator (or Android Studio > Preferences > Tools > Emulator on macOS), then select Launch in a tool window and click OK.
2. If the Emulator window didn't automatically appear, open it by clicking View > Tool Windows > Emulator.
3. Start your virtual device using the AVD Manager or by targeting it when running your app.

Limitations

Currently, you can't use the emulator's extended controls when it's running in a tool window. If your development workflow depends heavily on the extended controls, continue to use the Android Emulator as a standalone application. In addition, certain virtual devices—such as Android TV and foldable devices—can't be run in Android Studio because they have specialized UI requirements or important functions in the extended controls.

Database Inspector

With Android Studio 4.1 Canary 6 and higher, you can inspect, query, and modify your app's databases using the new Database Inspector. For example, you can debug your running app by modifying values in your database and testing those changes on the device.

To get started, deploy your app to a device running API level 26 or higher and select View > Tool Windows > Database Inspector from the menu bar.

If the Database Inspector window doesn't automatically select your app's process, select it from the dropdown menu.

Inspect and modify tables

In the Databases panel, you can see the database(s) for your app, and you can expand a database node to see its tables. When you double-click on a table, the inspector opens it in a separate tab on the right, as shown in the screenshot below, where you can inspect its data, sort by columns, or even modify values as your app is running on the device.

To change the value of a table cell, simply double-click into the cell, change its value, and press Enter. If you're using the Room persistence library and observing your databases (such as with LiveData), those changes should be visible in your running app almost immediately. Otherwise, you might need to refresh your app's query of the database to see your changes.

If your app makes updates to its database and you want to automatically see those updates in the inspector window, check the box next to Live updates. Keep in mind, while this option is enabled, the table in the inspector becomes read-only and you can not modify its values.

Alternatively, you can manually update the data in the inpector by clicking Refresh Table. Similarly, if there are changes to database schemas, click Refresh Schema in the Databases panel.

Query your database

To query a database, click Open New Query tab in the Databases panel. This opens a New Query tab on the right. If your app includes more than one database, select the database you want to query using the dropdown menu in the tab window. In the text field, you can specify your SQLite query and click Run. The inspector queries your app's database and returns the result, as shown below.

If you use the Room persistence library, Android Studio also provides gutter actions to help you quickly run queries you define in your @Query annotations. While your app is deployed to a compatible device and the Database Inspector is open in the IDE, click the button next to a @Query annotation, as shown below.

The Database Inspector opens a new tab, runs the query, and returns the results. If your query includes named bind parameters, such as :name, Android Studio requests values for each parameter before running the query.

Prevent new and existing databases from closing

If your app frequently connects to and disconnects from databases, it can be difficult to inspect those databases. That's because inspecting, querying, and modifying a database requires that your app maintain a live connection to it. The Database Inspector window uses icons to help you identify open () and closed () databases.

To make it easier to inspect those databases, you can prevent new and existing connections to your databases from closing by clicking Keep database connections open . When this behavior is enabled, the Keep database connections open button changes to .

Symbolication for native crash reports

When a crash or ANR occurs in native code, the system produces a stack trace, which is a snapshot of the sequence of nested functions called in your program up to the moment it crashed. These snapshots can help you to identify and fix any problems in the source, but they must first be symbolicated to translate the machine addresses back into human-readable function names.

If your app or game is developed using native code, like C++, you can now upload debug symbols files to the Play Console for each version of your app. The Play Console uses these debug symbols files to symbolicate your app's stack traces, making it easier to analyze crashes and ANRs.

How to upload debug symbols files

Before you can upload debug symbols files, you must be using Android Gradle plugin version 4.1 or higher.

How you upload your debug symbols files depends on whether you build your app using an Android App Bundle or an APK:

• Apps built using an Android App Bundle: If your project builds an Android App Bundle, you can automatically include the debug symbols file in it so that you don't have to upload the file manually. To include this file, add the following to your app's build.gradle file:

  android.defaultConfig.ndk.debugSymbolLevel = 'FULL'
  

• Apps built using an APK: If your project builds an APK, the debug symbols file is built separately. Add the following to your app's build.gradle file:

  android.defaultConfig.ndk.debugSymbolLevel = 'FULL'
  

  As part of the build process, the Android Gradle plugin outputs the debug symbols file to the following project location:

  app/build/outputs/native-debug-symbols/variant-name/native-debug-symbols.zip
  

  Upload this debug symbols file to the Play Console.

Native Memory Profiler

The Android Studio Memory Profiler now includes a Native Memory Profiler for apps deployed to physical devices running Android 10 or later. With a sample size of 32 bytes, the Native Memory Profiler tracks allocations/deallocations of objects in native code for a specific time period and provides the following information:

• Allocations: A count of objects allocated via malloc() or the new operator during the selected time period.
• Deallocations: A count of objects deallocated via free() or the delete operator during the selected time period.
• Allocations Size: The aggregated size in bytes of all allocations during the selected time period.
• Deallocations Size: The aggregated size in bytes of all freed memory during the selected time period.
• Total Count: The value in the Allocations column minus the value in the Deallocations column.
• Remaining Size: The value in the Allocations Size column minus the value in the Deallocations Size column.

To initiate a recording, click Record native allocations at the top of the Memory Profiler window:

When you're ready to complete the recording, click Stop recording.

Set the NDK path

You can set the path to your local NDK installation using the android.ndkPath property in your module's build.gradle file.

android {
   ndkPath "your-custom-ndk-path"
}

If you use this property together with the android.ndkVersion property, then this path must contain an NDK directory with the same version as android.ndkVersion.

Use TensorFlow Lite models

ML Model Binding makes it easy for you to directly import .tflite model files and use them in your projects. Android Studio generates easy-to-use classes so you can run your model with less code and better type safety.

Supported models

The current implementation of ML Model Binding supports image classification and style transfer models, provided they are enhanced with metadata. Over time, support will be expanded to other problem domains, like object detection, image segmentation, and text classification.

A wide range of pre-trained models with metadata are provided on TensorFlow Hub. You can also add metadata to a TensorFlow Lite model yourself, as is outlined in Adding metadata to TensorFlow Lite model.

Import a model file

To import a supported model file, follow these steps:

1. Open the TensorFlow Lite model import dialog in the File menu at File > New > Other > TensorFlow Lite Model.
2. Select the .tflite model file that you previously downloaded or created.
3. Click Finish.

This imports the model file into your project and places it in the ml/ folder; if the directory doesn't exist, Android Studio will create it for you.

View model metadata and usage

To see the details for an imported model and get instructions on how to use it in your app, double-click the model file in your project to open the model viewer page, which shows the following:

• Model: High-level description of the model
• Tensors: Description of input and output tensors
• Sample code: Example of how to interface with the model in your app

Here is an example using mobilenet_v1_0.25_160_quantized.tflite:

As the example demonstrates, Android Studio creates a class called MobilenetV1025160Quantized for interacting with the model.

If the model does not have metadata, this screen will only provide minimal information.

Known issues and workarounds

• Support for TensorFlow Lite models for problem domains other than image classification and style transfer is currently limited. Although import should work fine, some model inputs and/or outputs are represented by TensorBuffers rather than friendly types. For models without any metadata, all model inputs and outputs will be TensorBuffers.
• Models with Input and Output data types different from DataType.UINT8 or DataType.FLOAT32 are not supported.

This feature is still under development, so please provide feedback or report bugs.

Assertions in debug builds

Assertions in your Java code are now enabled when deploying the debug version of your app. Because the Android runtime doesn't support enabling assertions at runtime (that is, passing the equivalent of the -ea/-enableassertions flag to a Java VM), assertions in your app previously had no effect.

Now, when you build and deploy the debug version of your app using Android Gradle plugin 4.1.0-alpha01 and higher, the built-in compiler (D8) rewrites the code to enable assertions at compile time, so you always have the assertion checks active.

Apply Changes

To help you be more productive as you iterate on your app, we've made the following enhancements to Apply Changes for devices running Android 11 Developer Preview 3 or higher:

Faster deploy speeds

We've invested heavily in optimizing your iteration speed by developing a method to deploy and persist changes on a device without installing the application. After an initial deploy, subsequent deploys to Android 11 devices using either Apply Code Changes or Apply Changes and Restart Activity are now significantly faster.

To learn more about the difference between these two actions, see Apply Changes.

Support for additional code changes

For devices running Android 11 Developer Preview 3 or higher, you can now add methods and then deploy those changes to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity .

Export C/C++ dependencies from AARs

Android Gradle Plugin 4.0 added the ability to import [Prefab] packages in AAR dependencies as described below. Beginning with canary 10, version 4.1 enables exporting libraries from your external native build in an AAR for an Android Library project.

To export your native libraries, add the following to the android block of your library project's build.gradle file:

buildFeatures {
    prefabPublishing true
}

prefab {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/include"
    }
}

In this example, the mylibrary and myotherlibrary libraries from either your ndk-build or CMake external native build will be packaged in the AAR produced by your build, and each will export the headers from the specified directory to their dependents.

Prebuilt dependencies used by CMake

For users of Android Gradle plugin 4.0 and above, the configuration settings for importing prebuilt native libraries have changed. For more information, see the AGP release notes.

Known Issues for 4.1 Preview

This section describes current known issues in Android Studio 4.1 Preview.

Patches not working in 4.1 Canary 10

Patches for Android Studio 4.1 Canary 10 are currently broken. To update to a newer version of Android Studio 4.1, shut down Android Studio, then download and install the latest package.

This issue has been fixed in Android Studio 4.1 Beta 1.

Workaround for missing Kotlin plugin in Canary 9

In Android Studio 4.1 Canary 9, you may see the following error when first launching Android Studio after upgrading:

missing essential plugin org.jetbrains.android

This can happen when you import your settings from a previous version of Android Studio. Typically, this means you have a locally installed Kotlin plugin that is not compatible with the new IDE.

To fix this issue, remove the Kotlin directory from the following locations:

Linux: ~/.local/share/Google/AndroidStudioPreview4.1

Windows: C:\Users\YourUserName\AppData\Roaming\Google\AndroidStudioPreview4.1

MacOS: ~/Library/Application Support/Google/AndroidStudioPreview4.1

Because there is no Kotlin plugin compatible with Canary 9 currently available from JetBrains, we have bundled our own Kotlin plugin with the Canary 9 update, so you don't need to manually install a Kotlin plugin.

Timeout errors in CPU Profiler

You may experience "Recording failed to stop" errors in the Android Studio CPU Profiler when you select the Sample Java Methods or Trace Java Methods configurations. These are often timeout errors, especially if you see the following error message in the idea.log file:

Wait for ART trace file timed out

The timeout errors tend to affect traced methods more than sampled methods and longer recordings more than shorter recordings. As a temporary workaround, it may be helpful to try shorter recordings to see if the error disappears.

If you experience timeout issues with the Profiler, please file a bug that includes the make/model of your device(s) and any relevant entries from idea.log and logcat.

Git version control errors in the IDE

Operations requiring authentication in Git version control are broken in the IDE for Android Studio 4.1 Canary 1.

To fix this issue, upgrade to Android Studio 4.1 Canary 2.