New features in Android Studio Preview

Android Studio Bumblebee | 2021.1.1 has been released to the stable channel. Download it here.

Android Studio Chipmunk | 2021.2.1 is currently in the Canary and Dev channels.

Android Gradle plugin (AGP) 7.1 has been released to the stable channel. For more information, see the AGP release notes.

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

For updates on AGP API deprecations and removals, see the AGP API 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 Chipmunk | 2021.2.1

The following are new features in Android Studio Chipmunk.

Android Testing

Android Studio Chipmunk and AGP 7.2.0 introduce several new features and improvements to help you scale your automated instrumentation tests and see useful results you can use to debug issues. These are features in addition to the behavior change in Android Studio Bumblebee to run all instrumentation tests via Gradle, by default, allowing more consistent results with your remote testing solutions.

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. The build system uses the configurations to fully manage—that is, create, deploy, and tear down—those devices when executing 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

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

Get started

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

group-nameGroupBuildVariantAndroidTest

Run tests using Automated Test Devices

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

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

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

android {
  testOptions {
    devices {
      pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
        // Use device profiles you typically see in Android Studio
        device = "Pixel 2"
        // ATD currently support only API level 30.
        apiLevel = 30
        // You can also specify "google-atd" if you require Google Play Services.
        systemImageSource = "aosp-atd"
        abi = "x86"
      }
    }
  }
}

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

gradlew
pixel2api30DebugAndroidTest -Pandroid.sdk.channel=3

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

What's removed from ATD images?

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

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

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

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


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

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

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

Enable Test Sharding

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

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

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

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

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

Jetifier warning and check in Build Analyzer

Build Analyzer now displays a warning if your project's gradle.properties file includes android.enableJetifier=true. This flag was introduced in a previous version of Android Studio to enable AndroidX for libraries that don't support AndroidX natively. However, the library ecosystem has mostly moved to support AndroidX natively and the Jetifier flag is probably no longer needed by your project. Additionally, the flag can lead to slower build performance. If you see this warning, you can run a check within Build Analyzer to confirm if the flag can be removed.

Support for test fixtures

Starting with Android Studio Chipmunk Beta 1, Android Studio supports both Android and Java test fixtures. See Gradle's guide on using test fixtures for more information on the test fixtures feature and how to use it in a Java project.

To enable test fixtures in your Android library module, add the following to your library-level build.gradle file:

android {
    testFixtures {
        enable true

        // enable testFixtures's android resources (disabled by default)
        // androidResources true
    }
}

By default, publishing your library also publishes the test fixtures AAR with the main library. The Gradle Module Metadata file will contain information for Gradle to be able to consume the right artifact when requesting the testFixtures component.

To disable publishing the test fixtures AAR of a library in the release variant, add the following to your library-level build.gradle file:

afterEvaluate {
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseApiPublication) { skip() }
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseRuntimePublication) { skip() }
}

To consume the test fixtures AAR of a published Android library, you can use Gradle's helper method testFixtures().

dependencies {
    testImplementation testFixtures('com.example.company:publishedLib:1.0')
}

By default, lint will analyze test fixtures sources. You can configure lint to ignore test fixtures sources as follows:

android {
    lint {
        ignoreTestFixturesSources true
    }
}

Animation Preview support animatedVisibility

Android Studio Chipmunk supports the animatedVisibility API in Animation Preview. To use Animation preview with animatedVisibility, use Compose version 1.1.0 or higher. To learn more about Animation Preview, see Animations.