New features in Android Studio Preview

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

Android Studio 4.2 is currently in the Beta channel.

Android Studio Arctic Fox | 2020.3.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 Arctic Fox | 2020.3.1

Updated version numbering for Android Studio

We have changed the version numbering system for Android Studio to more closely align with IntelliJ IDEA, the IDE upon which Android Studio is built.

In the previous numbering system, this would have been Android Studio 4.3 or version 4.3.0.1. With the new numbering system, it is now Android Studio - Arctic Fox | 2020.3.1 Canary 1, or version 2020.3.1.1.

Going forward, here’s how the Android Studio version number is determined:

<Year of IntelliJ Version>.<IntelliJ major version>.<Studio major version>.<Studio minor/patch version>

• The first two number groups represent the version of the IntellIj platform that a particular Android Studio release is based on. For this release, that's version 2020.3.
• The third number group represents the Studio major version, starting at 1 and incrementing by one for every major release.
• The fourth number group represents the Studio minor/patch version, starting at 1 and incrementing by one for every minor release.
• We are also giving each major release a version name, incrementing from A to Z based on animal names. This release is named Arctic Fox.

Updated version numbering for Android Gradle plugin

We are updating the version numbering for Android Gradle plugin (AGP) to more closely match the underlying Gradle build tool. Therefore, AGP 7.0 will be the next release after AGP 4.2.

For more details, see Versioning changes in the AGP release notes.

Memory Profiler: Recording UI updated

In Android Studio Arctic Fox, we've consolidated the Memory Profiler UI for different recording activities, such as capturing a heap dump and recording Java, Kotlin, and native memory allocations.

The Memory Profiler provides the following options:

Here's how to use these three options:

• To capture a heap dump, select Capture heap dump, then click Record. After the profiler finishes capturing the heap dump, the Memory Profiler UI transitions to a separate screen displaying the heap dump.

  

• To record native allocations on devices running Android 10 and higher, select Record native allocations, then click Record. The recording continues until you click Stop , after which the Memory Profiler UI transitions into a separate screen displaying the native recording.

  On Android 9 and lower, the Record native allocations option is not available.

• To record Java and Kotlin allocations, select Record Java / Kotlin allocations, then click Record. If the device is running Android 8 or higher, the Memory Profiler UI transitions to a separate screen displaying the ongoing recording. You can interact with the mini timeline above the recording (to change the selection range, for example). Click Stop to complete the recording.

  

  On Android 7.1 and lower, the memory profiler uses legacy allocation recording, which displays the recording on the timeline until you click Stop.

New in app inspection

Export data from the Database Inspector

You can now easily export databases, tables, and query results from the Database Inspector to save, share, or recreate locally. When you open up an app project in Android Studio and inspect the app for that project in the Database Inspector, you can start exporting data in one of the following ways:

• Select a database or table in the Databases panel and click Export to file near the top of the panel.
• Right-click on a database or table in the Databases panel and select Export to file from the context menu.
• When inspecting a table or query results in a tab, click Export to file above the table or query results.

After selecting an export action, you should see the Export dialog to help you through the final steps, as shown below. Depending on whether you are trying to export a database, table, or query results, you have the option of exporting the data in one or more of the following formats: DB, SQL, or CSV.

New Background Task Inspector

In a previous version of Android Studio, we introduced the Database Inspector to help developers understand and debug their app’s SQLite databases. The Database Inspector is built on an App Inspection framework that was designed to support different types of inspectors, for different aspects of your app.

In Arctic Fox Canary 3 and higher, you can use the new Background Task Inspector, which helps you visualize, monitor, and debug your app's background workers when using WorkManager library 2.5.0 or higher.

You can now find both the Background Task Inspector and the Database Inspector by selecting View > Tool Windows > App Inspection from the menu bar. When you deploy an app using WorkManager 2.5.0 or higher on a device running API level 26 and higher, you should see active workers in the Background Task Inspector tab, as shown below.

You can then select a worker from the table to see more detailed information, such as a description of the worker, how it was executed, details of its worker chain, and the result of the execution of the worker.

To help you investigate issues from workers that fail execution, you can stop a currently running or enqueued worker by selecting it from the table and clicking Cancel Selected Worker from the toolbar. You can also filter workers in the table by tags you’ve assigned to them using the All tags dropdown menu.

If you want to see a visual representation of a worker chain, select a worker from the table and click Show Graph View from the toolbar. You can then select any worker in the chain to see its details, or stop it if it’s currently enqueued or running. To return to the table, click Show List View .

JDK 11 required to run AGP 7.0

When using Android Gradle plugin 7.0 to build your app, JDK 11 is now required to run Gradle. Android Studio Arctic Fox bundles JDK 11 and configures Gradle to use it by default, which means that most Android Studio users do not need to make any configuration changes to their projects.

If you need to manually set the JDK version used by AGP inside of Android Studio, go to File > Project Structure > SDK Location and set the JDK location property to the directory containing JDK 11.

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

C++: Use Natvis visualizers in native debugger

You can now use Natvis files to customize the way C++ objects are displayed in the native debugger.

To use this feature:

1. Define the objects you’d like to visualize using the XML format in a .natvis visualizer file.
2. Add the file to the cpp folder in your project, where it will be picked up and used by the debugger automatically.

In the following example, the visualizer for the MyClass type customizes the variable summary and defines two synthetic child variables sum and product, whose values are then displayed in the debugger window.

For more information on authoring Natvis files, see Microsoft’s documentation.

Compose support in the Layout Inspector

The Layout Inspector allows you to see rich detail about your app's layout running on your connected device. You can interact with your app and see live updates in the tool to quickly debug issues that might arise.

Starting with Arctic Fox Canary 6, you can now inspect layouts written with the new Android declarative UI framework, Jetpack Compose. Whether your app uses layouts fully written in Compose or layouts that use a hybrid of Compose and Views, the Layout Inspector helps you understand how your layouts are rendered on your running device.

Add dependencies

To show attributes for all of your app's Compose functions, the Layout Inspector requires that each module using the Compose UI declare the following dependencies.

// Use the most recent version of Compose available.
debugImplementation "androidx.compose.ui:ui-tooling:1.0.0-beta01"
debugImplementation "org.jetbrains.kotlin:kotlin-reflect:1.4.30"

Get started

To get started, deploy your app to a connected device and then open the Layout Inspector window by selecting View > Tool Windows > Layout Inspector. If the Layout Inspector doesn't automatically connect to your app process, select the desired app process from the process pulldown. You should soon see your app's layout rendered in the tool window. To get started inspecting your Compose layout, select the layout component visible in the rendering or select it from the Component Tree.

The Attributes window shows you detailed information about the Compose function currently selected. In this window, you can inspect the function's parameters and their values, including modifiers and lambda expressions. For lambda expressions, the inspector provides a shortcut to help you navigate to the expression in your source code.

The Layout Inspector shows all Compose functions in the call stack that emit components to your app's layout. In many cases, this includes Compose functions that are called internally by the Compose Library. If you want to see only the Compose functions in the Component Tree that your app calls directly, click the filter action, which might help reduce the number of nodes shown in the tree to the ones you are likely to want to inspect.

Emulator Snapshots for test failures

When you inspect failed assertions after running instrumented tests, it's sometimes difficult or time consuming to reproduce that test failure again. However, reproducing those failures on your connected device is critical in helping you diagnose the issue, either by attaching a debugger or interacting with the app at the time of failure.

In AGP 7.0-alpha13 and higher, we're introducing Emulator Snapshots for test failures – a quicker way to reproduce test failures when using the Android Emulator. In other words, when your instrumented tests running on a connected Emulator encounter a Java or Kotlin assertion that fails, the device takes a snapshot at the time of failure. After your test run completes, you can then reload the snapshot on the same device in order to reproduce and investigate that failure.

To get started, first update the Android Emulator to 30.4.3 or higher. Then, add the following to your app module's build.gradle file:

android {
      ...
    testOptions {
      emulatorSnapshots {
        // Enables the feature
        enableForTestFailures true
        // The number of snapshots to take during a test run. When not
        // specified, the default value is 2. After reaching the max number
        // of snapshots, subsequent assertion failures in a test run do not
        // generate additional snapshots. Keep in mind, snapshots can consume
        // a significant amount of disk space.
        maxSnapshotsForTestFailures 2
      }
      ...
    }
}

Next, start the Android Virtual Device you'd like to use and run your app's instrumented tests from the command line, as follows:

Linux and Mac

./gradlew connectedCheck

Windows

gradlew connectedCheck

Alternatively, if you don’t want to enable the feature in your app's build.gradle file, you can simply pass the following properties in the command line:

./gradlew
-Pandroid.experimental.androidTest.useUnifiedTestPlatform=true
-Pandroid.experimental.testOptions.failureRetention=2
connectedCheck

After the tests complete, you should see test results in the <project>/<module>/build/outputs/androidTest-results/connected/ folder. If your test run encountered an assertion failure, you should see a tar snapshot file for each snapshot that was taken. To see the results in Android Studio and load the snapshots to your running virtual device, select Run > Import Tests from File from the menu bar, navigate to the test-result.pb file from the test results directory, and click Open.

The Run window should appear and show you the results of your test run. To load a snapshot, select a failed test that indicates Test results in the column under the device name. In the right side of the tool window, select the Retention tab. After Android Studio validates the snapshot for that test failure, click the Start retention debug button to load the snapshot to your running device.

Compress snapshots

Snapshots provide high fidelity in reproducing your test failures, but they each consume a large amount of disk space. If you want to instead generate compressed snapshots, add the following to your build.gradle file. Keep in mind, compressing snapshots increases the time it takes to complete the process and continue with the test execution.

android {
      ...
    testOptions {
      failureRetention {
        ...
        // Generates snapshots that are compressed into a single TAR file.
        compressSnapshots true
      }
      ...
    }
}

Alternatively, you can pass the following property from the command line.

`./gradlew`
-Pandroid.experimental.testOptions.compressSnapshots=true
connectedCheck

C++ editor: Set execution point in debugger

In the C++ code editor window, you can set an arbitrary execution point when running your app in the debugger. This feature is useful when you want to break out of a loop or force a different path with branching code.

To use this feature, set a breakpoint in your code and run your app in the debugger. When the program reaches this breakpoint, drag and drop the yellow arrow to the line of code you would like to execute next, bypassing any instructions in between the breakpoint and the new execution point.

Note that changing the execution point does not alter memory content (stack or heap) or other application state; for example, local variables on the stack retain their values even after execution point changes.

This feature is available for arm64-v8a, armeabi-v7a, and x86_64 ABIs, but is unavailable for the 32-bit x86 ABI.

This feature is based on the underlying functionality in JetBrains’ CLion editor. For more information about this feature and its limitations, see this blog post from JetBrains.

StateFlow support in data binding

For Kotlin apps that use coroutines, you can now use StateFlow objects as a data binding source to automatically notify the UI about changes in the data. Your data bindings will be lifecycle aware and will only be triggered when the UI is visible on the screen.

To use a StateFlow object with your binding class, you need to specify a lifecycle owner to define the scope of the StateFlow object, and in your layout, assign the properties and methods of your ViewModel component to the corresponding views using binding expressions, as shown in the following example:

class ViewModel() {
   val username: StateFlow<String>
}

<TextView
    android:id="@+id/name"
    android:text="@{viewmodel.username}" />

If you're in a Kotlin app that uses AndroidX, StateFlow support is automatically included in the functionality of data binding, including the coroutines dependencies.

To learn more, see Work with observable data objects.

Android Studio now uses Gradle test runner

To improve overall consistency of test executions, Android Studio now uses Gradle to run all unit tests by default. In many cases, this change will not affect your testing workflow in the IDE.

For example, when you click the Run command in the context menu (visible when you right-click on a test class) or its corresponding gutter action , Android Studio will use the Gradle run configuration by default to run unit tests.

However, Android Studio no longer recognizes existing Android JUnit run configurations, so you should migrate Android JUnit run configurations that you might save as project files to Gradle run configurations.

To create a Gradle test configuration, select the Gradle template when following the instructions in Create a new run/debug configuration. When you've created a new configuration, it will appear in the Edit Configurations dialog in the Gradle section:

If you want to inspect Android JUnit configurations that are no longer recognized, you can do one of two things:

• Open manually saved configurations in a text editor. The locations of these files are specified by the user, but the files typically appear in <my-app>/.idea/runConfigurations/.

• Look for temporary configurations in <my-app>/.idea/workspace.xml and look under the <component name="RunManager" ...> node. For example:

  <component name="RunManager" selected="Gradle.PlantTest">
  …
  <configuration name="PlantTest" type="AndroidJUnit" factoryName="Android JUnit" nameIsGenerated="true">
        <module name="Sunflower.app" />
        <useClassPathOnly />
        <extension name="coverage">
          <pattern>
            <option name="PATTERN" value="com.google.samples.apps.sunflower.data.*" />
            <option name="ENABLED" value="true" />
          </pattern>
        </extension>
        <option name="PACKAGE_NAME" value="com.google.samples.apps.sunflower.data" />
        <option name="MAIN_CLASS_NAME" value="com.google.samples.apps.sunflower.data.PlantTest" />
        <option name="METHOD_NAME" value="" />
        <option name="TEST_OBJECT" value="class" />
        <option name="PARAMETERS" value="" />
        <option name="WORKING_DIRECTORY" value="$MODULE_DIR$" />
        <method v="2">
          <option name="Android.Gradle.BeforeRunTask" enabled="true" />
        </method>
      </configuration>
  

Android Gradle plugin 7.0

Known issue: Incompatibility with Kotlin Multiplatform plugin

Versions of the Kotlin Multiplatform plugin that use Kotlin 1.4.x and below are not compatible with Android Gradle plugin 7.0.0. As a workaround for projects using Kotlin Multiplatform, downgrade Android Gradle plugin to 4.2.x. Alternatively, upgrade the Kotlin Multiplatform plugin to a version using Kotlin 1.5.0 or higher.

For more information, see KT-43944.

Missing class warnings in R8 shrinker

Starting in AGP 7.0.0-alpha10, R8 will more precisely and consistently handle missing classes and the -dontwarn option. Therefore, you should start to evaluate the missing class warnings emitted by R8.

When R8 encounters a class reference that is not defined in your app or one of its dependencies, it will emit a warning that appears in your build output. For example:

R8: Missing class: java.lang.instrument.ClassFileTransformer

This warning means that the class definition java.lang.instrument.ClassFileTransformer could not be found when analyzing your app’s code. While this usually means there is an error, it’s possible that you may want to ignore this warning. Two common examples of this are:

1. Libraries that are targeting the JVM and the missing class is a JVM library type (as in the example above).
2. One of your dependencies uses a compile-time only API.

You can ignore a missing class warning by adding a -dontwarn rule to your proguard-rules.pro file. For example:

-dontwarn java.lang.instrument.ClassFileTransformer

As a convenience, AGP will generate a file that contains all potentially missing rules, writing them to a file path such as the following: app/build/outputs/mapping/release/missing_rules.txt. These rules can be added your proguard-rules.pro file to ignore warnings.

In AGP 7.0, missing class messages will appear as warnings and you can turn them into errors by setting android.r8.failOnMissingClasses=true in gradle.properties. In AGP 8.0, these warnings will become errors that break your build. It is possible, however, to keep the AGP 7.0 behavior by adding the option -ignorewarnings to your proguard-rules.pro file, but that is not recommended.

Android Gradle plugin build cache removed

The AGP build cache was removed in AGP 4.1. Previously introduced in AGP 2.3 to complement the Gradle build cache, the AGP build cache was superseded entirely by the Gradle build cache in AGP 4.1. This change does not impact build time.

In AGP 7.0, the android.enableBuildCache and android.buildCacheDir properties and the cleanBuildCache task have been removed.

Use Java 11 source code in your project

You can now compile up to Java 11 source code in your app’s project, enabling you to use newer language features like private interface methods, the diamond operator for anonymous classes, and local variable syntax for lambda parameters.

To enable this feature, set compileOptions to the desired Java version and set compileSdkVersion to 30 or above:

// build.gradle.kts

android {
    compileSdkVersion(30)

    compileOptions {
      sourceCompatibility(JavaVersion.VERSION_11)
      targetCompatibility(JavaVersion.VERSION_11)
    }

    kotlinOptions {
      jvmTarget = "11"
    }
}

// build.gradle

android {
    compileSdkVersion 30

    compileOptions {
      sourceCompatibility JavaVersion.VERSION_11
      targetCompatibility JavaVersion.VERSION_11
    }

    // For Kotlin projects
    kotlinOptions {
      jvmTarget = "11"
    }
}

Dependency configurations removed

In AGP 7.0 Canary 3, the following configurations (or dependency scopes) have been removed:

• compile
  Depending on use case, this has been replaced by api or implementation.
  Also applies to *Compile variants, for example: debugCompile.
• provided
  This has been replaced by compileOnly.
  Also applies to *Provided variants, for example: releaseProvided.
• apk
  This has been replaced by runtimeOnly.
• publish
  This has been replaced by runtimeOnly.

In most cases, the AGP Upgrade Assistant will automatically migrate your project to the new configurations.

Classpath change when compiling against Android Gradle plugin

If you are compiling against the Android Gradle plugin, your compile classpath may change. Because Android Gradle plugin now uses api/implementation configurations internally, some artifacts may be removed from your compile classpath. If you depend on an Android Gradle plugin dependency at compile-time, be sure to add it as an explicit dependency.

Accessibility Scanner for Layout Editor

Android Studio now integrates with the Android Accessibility Test Framework to help you find accessibility issues in your layouts. When using the Layout Editor, click on the Accessibility Scanner button to launch the scanner. The tool also offers suggested fixes for some common problems such as missing content descriptions.

Accessibility Scanner is available starting in Canary 8.

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.

Jetpack Compose tooling support in Arctic Fox | 2020.3.1

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"
   }
}

New test matrix for multi-device testing

Starting in Android Studio Arctic Fox, 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. Choose Select Multiple Devices in the target device dropdown menu (in the top-center of the IDE).

   

2. Select the target devices and click OK.

   

3. 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.

Known issues for Compose preview

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

Known Issues for Arctic Fox Preview

This section describes current known issues in Android Studio Arctic Fox Preview.

Update patches not working for Canary 2

On Linux and macOS machines, update patches are not working for Canary 2. To upgrade to the Canary 2 release, download and install the full version.

Android Studio 4.2

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

Configure app signing per variant

It is now possible to enable or disable app signing in Android Gradle plugin per variant.

This example demonstrates how to set app signing per variant using the onVariants() method in either Kotlin or Groovy:

androidComponents {
    onVariants(selector().withName("fooDebug"), {
        signingConfig.enableV1Signing.set(false)
        signingConfig.enableV2Signing.set(true)
    })

Gradle compatibility and configuration changes

When running in Android Studio, the Gradle build tool uses Studio's bundled JDK. In previous releases, JDK 8 was bundled with Studio. In 4.2, however, JDK 11 is now bundled instead. When using the new bundled JDK to run Gradle, this may result in some incompatibility or impact JVM performance due to changes to the garbage collector. These issues are described below.

Studio compatibility with Android Gradle plugin (AGP)

Android Studio 4.2 can open projects that use AGP 3.1 and higher provided that AGP is running Gradle 4.8.1 and higher. For more information about Gradle compatibility, see Update Gradle.

Optimizing Gradle builds for JDK 11

This update to JDK 11 impacts the default configuration of the JVM garbage collector, since JDK 8 uses the parallel garbage collector while JDK 11 uses the G1 garbage collector.

To potentially improve build performance, we recommend testing your Gradle builds with the parallel garbage collector. In gradle.properties set the following:

org.gradle.jvmargs=-XX:+UseParallelGC

If there are other options already set in this field, add a new option:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

To measure build speed with different configurations, see Profile your build.

System Trace: Improved metrics for memory and graphics

In the CPU profiler, the System Trace feature now includes new metrics for analyzing app performance.

Events Table

The Events table is a new tab on the right-hand side of the Analysis pane. This table lists all trace events in the currently selected thread.

New tracks and track groups

More data is now available in System Trace for traces of apps deployed to devices running Android 9 or higher.

BufferQueue (in the Display section)

This new track shows the buffer count of the app's surface BufferQueue (0, 1 or 2). It can help you understand the state of image buffers as they move between the Android graphics components. For example, a value of 2 means the app is currently triple-buffered, which may result in extra input latency.

CPU Frequency (in the CPU cores section)

In addition to CPU scheduling data, we also included CPU frequency by core. This shows how hard each core is working and may give you an idea of which ones are the "big" or "little" cores in modern mobile processors.

Process Memory (RSS)

The new Process Memory (RSS) shows the amount of physical memory currently in use by the app.

Total

This is the total amount of physical memory currently in use by your process. On Unix-based systems, this is known as the "Resident Set Size", and is the combination of all the memory used by anonymous allocations (those backed by the swap file), file mappings (files which are loaded into memory a page at a time), and shared memory allocations (accessed by multiple processes, and allocated by a variety of mechanisms).

For Windows developers, Resident Set Size is analogous to the Working Set Size.

Allocated

This counter tracks how much physical memory is currently used by the process’s normal memory allocations. These are allocations which are both anonymous (not backed by a specific file) and private (not shared).

File Mappings

This counter tracks how much physical memory is being used by any file mappings owned by the process.

Shared

This counter tracks how much physical memory is being used to share memory between this process and other processes in the system.

R8 retrace now available in command-line tools

Available in version 4.0 of the command-line tools, R8 retrace is a standalone tool for obtaining the original stack trace from an obfuscated stack trace.

You can download this package with the SDK manager, which installs R8 retrace in android_sdk/cmdline-tools. Alternatively, you can download the standalone command-line tools package.

For usage information, see R8 retrace in the user guide.

New Layout Inspector refresh action

Introduced in Android Studio 4.0, the Layout Inspector was designed for real-time inspection of your running app’s UI stack. However, you might not always want the Layout Inspector to immediately reflect what’s happening in your app, since you might want to inspect a snapshot of your app’s layout at a specific point in time or minimize the performance impact of live updates on your app.

Pause live updates and refresh the screen capture in the Layout Inspector.

To manually load a snapshot of UI data from your app, first disable the Live updates option. You can then click the Refresh button to take a new snapshot of the UI stack for inspection. The Layout Inspector now remembers your preference to keep Live updates enabled or disabled between sessions.

Android Gradle plugin support for Jetpack Compose

Starting with Android Gradle Plugin 4.2 Canary 13, only Jetpack Compose Compiler 1.0.0-alpha-04 and higher will be supported.

Upgrade Assistant for AGP

Starting in Android Studio 4.2 Canary 5, an Upgrade Assistant for Android Gradle plugin can help you update the AGP version for your project.

Built on top of the existing AGP upgrade functionality, this tool guides you through project-wide updates/refactorings and includes a preview of the updates to help prevent potential breaking changes before executing the AGP upgrade.

Support for Safe Args

Safe Args is a Gradle plugin that generates simple object and builder classes for type-safe navigation and access to any associated arguments. Android Studio 4.2 Canary 9 and higher includes special support when working with Safe Args, as described below:

• Autocompletions for Directions, Args, and the various builder classes
• Support for both Java and Kotlin safe args plugins
• Navigation from source to XML

Database Inspector

Query editor improvements

The Database Inspector includes some improvements to help you write and execute your custom SQL statements. When you open the inspector and open a New query tab, you should notice a larger, resizable editor surface to author and format your queries, as shown below.

Additionally, we now provide a history of your previous queries. When you click on the Show query history button, you should see a list of queries you previously ran against the currently selected database. Click a query in the list to see a preview of the full query in the editor and press Enter to copy it to the editor. Then, click Run to execute the statement.

Offline mode

In previous versions of Android Studio, disconnecting from an app process while using the Database Inspector resulted in closing the inspector and its data. In Android Studio 4.2 Canary 8 and higher, we've added the ability to keep inspecting your app's databases after a process disconnects, making it easier to debug your app after a crash.

When a disconnect occurs, the Database Inspector downloads your databases and then makes them available to you in offline mode. When offline, you can open tables and run queries.

Keep in mind, when you reconnect to a live app process, the Database Inspector returns to live mode and shows you only the data that is on the device. That is, data shown in offline mode doesn't persist when you reconnect to an app process. Because of this, the Database Inspector does not allow editing or running modification statements while in offline mode.

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.

Android Gradle plugin 4.2

New Gradle property: android.native.buildOutput

To reduce clutter in build output, AGP 4.2 filters messages from native builds that use CMake and ndk-build, displaying only C/C++ compiler output by default. Previously, a line of output was generated for every file that was built, resulting in a large quantity of informational messages.

If you would like to see the entirety of the native output, set the new Gradle property android.native.buildOutput to verbose.

You can set this property in either the gradle.properties file or through the command line.

gradle.properties
android.native.buildOutput=verbose

Command line
-Pandroid.native.buildOutput=verbose

The default value of this property is quiet.

Behavior change for gradle.properties files

Starting in AGP 4.2, it is no longer possible to override Gradle properties from subprojects. In other words, if you declare a property in a gradle.properties file in a subproject instead of the root project, it will be ignored.

As an example, in previous releases, AGP would read values from projectDir/gradle.properties, projectDir/app/gradle.properties, projectDir/library/gradle.properties, etc. For app modules, if the same Gradle property was present in both projectDir/gradle.properties and projectDir/app/gradle.properties, the value from projectDir/app/gradle.properties would take precedence.

In AGP 4.2, this behavior has been changed, and AGP won't load values from gradle.properties in subprojects (e.g., projectDir/app/gradle.properties). This change reflects the new Gradle behavior and supports configuration caching.

For more information on setting values in gradle.properties files, see the Gradle docs.

Java language version 8 by default

Starting in version 4.2, AGP will use the Java 8 language level by default. Java 8 provides access to a number of newer language features including lambda expressions, method references, and static interface methods. For the full list of supported features see the Java 8 documentation.

To keep the old behavior, specify Java 7 explicitly in your module-level build.gradle.kts or build.gradle file:

// build.gradle.kts

android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_7
    targetCompatibility = JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

// build.gradle

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

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 APK 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.

Deploy to multiple devices

To help streamline app testing across devices and API levels, you can now deploy your app to multiple devices or emulators simultaneously by following these steps:

1. Choose Select Multiple Devices in the target device dropdown menu (in the top-center of the IDE).

   

2. Select the target devices and click OK.

   

3. Run your app or tests.

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 or higher:

Support for additional code changes

For devices running Android 11 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_SDK_HOME environment variable deprecated

The ANDROID_SDK_HOME environment variable is deprecated and has been replaced with ANDROID_PREFS_ROOT. For more information, see Emulator Environment Variables.

Known Issues for 4.2 Preview

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

Lint exceptions in Kotlin projects

Kotlin projects that set checkDependencies=true may encounter null pointer exceptions or the following error:

Lint error: package fragment is not found for module

For potential workarounds, see Lint exceptions in Kotlin projects.

Native Memory Profiler: Profiling app startup disabled

Profiling native memory on app startup has been disabled. This option will be enabled in an upcoming release.

As a workaround, you can use the Perfetto standalone command-line profiler to capture startup profiles.

Studio doesn’t start after installing Canary 8

After upgrading Android Studio to 4.2 Canary 8, the IDE may not start for certain users who set custom VM options in the .vmoptions file. To work around this issue, we recommend commenting out custom options in .vmoptions (using the “#” character). The .vmoptions file can be found in the following locations:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudioPreview4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudioPreview4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudioPreview4.2/studio64.vmoptions