New features in Android Studio Preview

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

Android Studio Bumblebee | 2021.1.1 is currently in the Canary and Dev channels, and Android Studio Arctic Fox | 2020.3.1 is currently in the Beta channel.

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 Bumblebee | 2021.1.1

Android Testing

Android Studio Bumblebee introduces several new features and improvements to help you more reliably and scalably run your automated instrumentation tests and see useful results you can use to debug issues. These are features in addition to those launched in Android Studio Arctic Fox, such as parallel device testing and Gradle test runner for unit tests.

Unified Gradle test runner

When running instrumented tests, previous versions of Android Studio used the IntelliJ Android instrumented test runner. Meanwhile, the Android Gradle plugin uses Gradle’s own implementation of the Android instrumented test runner. So, depending on whether you run your tests from Android Studio or from the command line using the Gradle plugin, such as on your continuous integration server, you might see different test results, such as tests passing using one runner and failing on another.

To resolve this issue, Android Studio Bumblebee now also uses Gradle’s Android instrumented test runner when running your tests. Now, when running your automated instrumentation tests from Android Studio, your results are more likely to be consistent with those you run using the Android Gradle plugin from the command line.

To enable using Gradle test runner from Android Studio, do the following:

1. Select File > Settings > Build, Execution, Deployment > Testing (or Android Studio > Preferences > Build, Execution, Deployment > Testing on MacOS.)
2. Check the box next to Run Android instrumented tests using Gradle and click OK.

If you already have instrumented test configurations saved to your project, they’ll now use Gradle to run tests on your connected device. Otherwise, you can create a new instrumented test configuration using the gutter action next to your test class or method, as shown below.

When running your instrumented tests, you can confirm that Android Studio is using the Gradle test runner by inspecting the test output in the Test Matrix for Gradle task output. Although we are improving this feature with each release of Android Studio, there are some known issues, as documented below. If you experience any issues, please report a bug.

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 allows you to configure virtual test devices in your project's Gradle files that the build system uses to fully manage—that is, create, deploy, and tear down—those devices to execute your automated tests.

Because this feature grants Gradle visibility into not only the tests you’re running, but also the devices’ lifecycle, it’s able to improve 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

Get started

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 29 as a Gradle managed device.

android {
  testOptions {
    devices {
      pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) {
        // Use device profiles you typically see in Android Studio
        device = "Pixel 2"
        apiLevel = 29
        // You can also specify "aosp" if you don’t require Google Play Services.
        systemImageSource = "google"
        abi = "x86"
      }
    }
  }
}

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 pixel2api29), and BuildVariant is the build variant of your app you want to test.

gradlew
-Pandroid.experimental.androidTest.useUnifiedTestPlatform=true
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 {
    devices {
      pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
      nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
    deviceGroups {
      phoneAndTablet {
        targetDevices.addAll(devices.pixel2api29, devices.nexus9api30)
      }
    }
  }
}

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

gradlew -Pandroid.experimental.androidTest.useUnifiedTestPlatform=true
group-nameGroupBuildVariantAndroidTest

Compatibility with Emulator Snapshots for test failures

Test runs using Gradle managed devices are compatible with Emulator snapshots for test failures. That is, when you enable snapshots for test failures when running tests with managed devices, Gradle will also generate a snapshot for each test assertion failure, so that you can use them to debug the issue later. To use managed virtual devices with Emulator snapshots for test failures enabled, simply include the command-line flag to enable snapshots.

$ gradlew
-Pandroid.experimental.androidTest.useUnifiedTestPlatform=true
-Pandroid.experimental.testOptions.emulatorSnapshots.maxSnapshotsForTestFailures=2
phoneAndTabletGroupDebugAndroidTest

Keep in mind, to use the snapshots, you’ll need to import the test results into Android Studio.

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.

When using Android Studio Bumblebee with In Android Gradle plugin 7.0-alpha13 and higher, you can use 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 follow these steps:

1. Select File > Settings > Build, Execution, Deployment > Testing (or Android Studio > Preferences > Build, Execution, Deployment > Testing on a MacOS.)
2. Check the box next to Run Android instrumented tests using Gradle and click OK.
3. Select Run > Edit Configurations … from the menu bar.
4. If you don’t already have an instrumented test configuration, create an instrumented test configuration you want to run.
5. Open the instrumented test configuration and select Yes from the dropdown next to Enable Emulator Snapshots for test failures.
6. By default, Android Studio generates up to two snapshots per device, per test run. To change this maximum number of snapshots, enter the desired amount next to Max Snapshots per test run.
7. If you want to compress snapshots, check the box next to Compress snapshots.
8. Click OK.
9. Deploy your tests to a virtual device as you normally would.

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 a device. You can then attach a debugger to investigate the cause of the issue.

Enable snapshots for command-line tests

You can enable emulator snapshots for tests you run from the command line in one of two ways: by enabling it in your app module’s build.gradle file or by passing parameters to the Gradle connectedCheck task. To enable the feature in your Gradle buildscript, include the following in 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

Import test failures into Android Studio

If you’re running your tests from outside of Android Studio, you need to import your test results into the IDE in order to use any of the generated snapshots.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.

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

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 > Settings... > Build, Execution, Deployment > Build Tools > Gradle (Android Studio > Preferences... > Build, Execution, Deployment > Build Tools > Gradle on a Mac) and set the Gradle JDK 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-beta07"
debugImplementation "org.jetbrains.kotlin:kotlin-reflect:1.4.32"

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.

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

android {
    compileSdkVersion 30

    compileOptions {
      sourceCompatibility JavaVersion.VERSION_11
      targetCompatibility JavaVersion.VERSION_11
    }

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

// build.gradle.kts

android {
    compileSdkVersion(30)

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

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

    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.