New features in Android Studio Preview

Android Studio Arctic Fox | 2020.3.1 has been released to the stable channel. Download it here.

Android Studio Bumblebee | 2021.1.1 is currently in the Beta channel, and Android Studio Chipmunk | 2021.2.1 is currently in the Canary and Dev channels.

Android Gradle plugin (AGP) 7.0 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.

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.

RenderScript is deprecated

Starting with Android Gradle plugin 7.2, the RenderScript APIs are deprecated. They will continue to function, but will invoke warnings, and will be completely removed in future versions of AGP. For guidance on how to transition off of RenderScript, see Migrate from RenderScript.

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.

Android Studio Bumblebee | 2021.1.1

The following are new features in Android Studio Bumblebee.

Lint analysis task is now cacheable

The AndroidLintAnalysisTask is now compatible with the Gradle build cache. If you enable the build cache by setting org.gradle.caching=true in your gradle.properties file, the lint analysis task will get its output from the build cache when possible.

The lint analysis task is often the biggest bottleneck when running lint with the Android Gradle plugin, so enabling the build cache improves build speed when running lint in many situations. You should see a noticeable performance improvement, for example, if you have a multi-module project and clean your build directory before running lint on your CI server.

C/C++ modules may now reference other C/C++ modules in the same project

A Gradle Android module with C/C++ code may now be set up to reference header files and library code in another Gradle module. The Prefab protocol is used to communicate the headers and libraries between Gradle modules.

Requirements

• The consuming module must be CMake and not ndk-build. Support for ndk- build will require a future NDK update. The publishing module may be CMake or ndk-build.

• The consuming module must enable prefab in the build.gradle file.

android {
  buildFeatures {
    prefab true
  }
}

• The publishing module must enable prefabPublishing in the build.gradle file.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• The consuming module must reference the publishing module by adding a line in the build.gradle file dependencies block. For example:

dependencies {
  implementation project(':mylibrary')
}

• The publishing module must expose a package using a prefab section. For example:

android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}

• The consuming module's CMakeLists.txt file may use find_package() to locate the package published by the producing module. For example:

find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
        myapplication
        mylibrary::mylibrary)

• There must be one STL for the entire application. So, for example, both consuming and publishing modules can use C++ shared STL.

   android {
defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

For further explanation of how to configure native AAR consumers and producers with AGP, see Native dependencies with AGP.

Support for KMP test execution

Starting from Android Studio Bumblebee Canary 13, you can run tests for Kotlin Multiplatform (KMP) projects from Android Studio

In order to ensure your tests run successfully from Android Studio, make sure you have all the requirements below:

• AGP 7.0.0-alpha08 or higher
• Gradle 6.8.2 or higher
• Kotlin plugin 1.4.30 or higher

Repository settings in settings.gradle file

When a new project is created in Android Studio Bumblebee, the top-level build.gradle file contains the plugins block, followed by code to clean your build directory:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}

task clean(type: Delete) {
  delete rootProject.buildDir
}

The repository settings that were previously in the top-level build.gradle file are now in the settings.gradle file:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}

dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

The module-level build.gradle file has not changed. So, use the top-level build.gradle file and the settings.gradle file to define build configurations that apply to all modules in your project, or the repositories and dependencies that apply to Gradle itself; use the module-level build.gradle file to define build configurations that are specific to a given module within your project.

New Device Manager

The Device Manager is a stand-in replacement for the AVD Manager, both from Android Studio’s Welcome Screen or after you open a project. The Device Manager introduces some new capabilities that make this feature more easy to create and manage all of your local test devices, such as:

• A more flexible UI that supports being docked in the IDE, floating, or in a separate window, like you can with other Android Studio tool windows. This gives you easier access to your devices without obstructing other windows of the IDE.
• A Virtual tab that allows you to create, manage, and deploy virtual devices; see details of each device at a glance; or quickly inspect the device in the Device File Explorer with a single click.
• A Physical tab that allows you to quickly pair to a new device using ADB Wifi and see details of each physical device at a glance. You can also quickly inspect each device’s file system using the Device File Explorer with a click of a button.

To open the new Device Manager, do one of the following:

• From the Android Studio Welcome screen, select More Actions > Virtual Device Manager.

• After opening a project, select View > Tool Windows > Device Manager from the main menu bar.

New in Layout Inspector

Capture layout hierarchy snapshots

Layout Inspector now allows you to save snapshots of your running app’s layout hierarchy, so that you can easily share them with others or refer to them later.

Snapshots capture the data you would typically see when using the Layout Inspector, including a detailed 3D rendering of your layout, the component tree of your View, Compose, or hybrid layout, and detailed attributes for each component of your UI. To save a snapshot, do the following:

1. Deploy your app to a device running API level 23 or higher
2. Open the Layout Inspector by selecting View > Tool Windows > Layout Inspector.
3. The Layout Inspector should connect to your app process automatically. If not, select the app process from the dropdown menu.
4. When you want to capture a snapshot, click Export snapshot from the Layout Inspector toolbar.
5. In the system dialog that appears, specify the name and location you want to save your snapshot. Make sure to save the file with a *.li extension.

You can then load a Layout Inspector snapshot by selecting File > Open from the main menu bar, and opening a *.li file.

Support for inspecting Compose semantics

In Compose, Semantics describe your UI in an alternative manner that is understandable for Accessibility services and for the Testing framework. In Android Studio Bumblebee, you can now use the Layout Inspector to inspect semantic information in your Compose layouts.

When selecting a Compose node, use the Attributes window to check whether it declares semantic information directly, merges semantics from its children, or both. To quickly identify which nodes include semantics, either declared or merged, use select the View options dropdown in the Component Tree window and select Highlight Semantics Layers. This highlights only the nodes in the tree that include semantics, and you can use your keyboard to quickly navigate between them.

Avoid Activity restarts

Connecting the Layout Inspector to a running app on older versions of Android Studio would cause your app’s Activity to restart. This is required to set a device flag that enables inspection of your app’s layouts.

In Android Studio Bumblebee, you can avoid Activity restarts when connecting the Layout Inspector by setting this flag ahead of time using one of the following steps:

• Enable a Run Configuration option

  1. Select Run > Edit Configurations from the main menu bar. The Run/Debug Configurations dialog appears.
  2. Navigate to the run configuration you would like to use.
  3. In the Layout Inspector options section, check the box next to Connect to Layout Inspector without restarting activity.
  4. Use the run configuration the next time you want to inspect your app using the Layout Inspector.

• Set the flag from the command line:

  1. Open a terminal window on the machine that’s connected to your device
  2. Set the device flag for your app using the following command:

  adb shell settings put global debug_view_attributes_application_package <my_package_name>
  

  1. Deploy your app to the device and connect the Layout Inspector. Android Studio will check whether the flag is set and avoid restarting the Activity if possible.

New in App Inspection

In Android Studio Bumblebee, there are new tools and functionalities in the App Inspection window. You can open the App Inspector by selecting View > Tool Windows > App Inspection from the main menu bar.

Network Inspector

The Network Profiler in the Profilers tool window has now moved to the App Inspection tool window. If you’ve previously used the Network Profiler, all the same features and rich network traffic data is still available. Simply deploy your app to a device running API level 26 and higher and open the App Inspector > Network Inspector tab.

Inspect Jobs, Alarms, and Wakelocks

The Background Task Inspector now allows you to inspect your app’s Jobs, Alarms, and Wakelocks, in addition to the existing support for inspecting Workers. Each type of asynchronous task now appears under the appropriate heading in the inspector tab, allowing you to easily monitor its status and progress. Similar to Workers, you can select a Job, Alarm, or Wakelock to inspect its detailed information in the Task Details panel.

Because Workers use Jobs and Wakelocks under the hood, those tasks that are scheduled by Workers appear as children of each Worker. Keep in mind, you can only see Workers in the Graph mode.

Android Testing

Android Studio Bumblebee Canary 8 and AGP 7.1.0 alpha-08 introduce 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.

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. If you are experiencing issues, please report a bug. You can also disable the new testing pipeline to revert to the old behavior.

Android Emulator now runs directly inside Android Studio by default

Launching the emulator inside Studio conserves screen real estate, and gives you the ability to write and test your apps inside one window without leaving Android Studio.

When the emulator is running, you'll have access to common emulator actions like rotating, and extended control options like navigation playback. To run the emulator in a separate window instead go to File > Settings > Tools > Emulator and deselect Launch in a tool window.

Disable the new testing pipeline

By default Android Studio Bumblebee uses Gradle to run its instrumentation tests. If you're experiencing issues, you can disable this behavior as follows:

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

If you're using AGP 7.1.0-alpha08 and higher, you can also revert to older behaviors by doing one of the following:

• When running Gradle tasks from the command line, use the following command line parameter: -Pandroid.experimental.androidTest.useUnifiedTestPlatform=false
• Add the following parameter to your project's gradle.properties file: android.experimental.androidTest.useUnifiedTestPlatform=false

To help resolve issues that you might be expereincing, please report a bug.

Improved resource shrinker

Android Studio Bumblebee includes an improved resource shrinker that helps reduce your app size.

Support for apps with dynamic features

The default implementation of the Android resource shrinker has been updated in Android Gradle Plugin 7.1.0-alpha09. The new implementation supports shrinking apps with dynamic features.

Experimental further app size reductions

The new resource shrinker implementation can reduce the size of your shrunk app even more by modifying the resource table to remove unused value resources and references to unused file resources. The new resource shinker can delete unused file resources completely, reducing the size of your app more. This behavior is not enabled by default yet, but you can opt in to try it by adding the experimental option android.experimental.enableNewResourceShrinker.preciseShrinking=true to your project's gradle.properties file.

Please report any issues you find with the new resource shrinker or the experimental flag. To help diagnose issues, or as a temporary workaround, you can switch back to the previous implementation by adding android.enableNewResourceShrinker=false to your project's gradle.properties. The new shrinker replaces unused file-based resources with slightly different minimal files than the previous resource shrinker, but this is not expected to have any runtime impact.

The old implementation is scheduled to be removed in Android Gradle plugin 8.0.0.

Build variant publishing

Android Gradle plugin 7.1.0 and higher allows you to configure which build variants to publish to an Apache Maven repository. AGP creates a component with a single or multiple build variants based on the new publishing DSL, which you can use to customize a publication to a Maven repository. Compared to previous versions, this also avoids unnecessary work, as no components will be created by default. To learn more, see the publishing code sample.

Publish Javadoc JAR

AGP 7.1.0 and higher allows you to generate Javadoc from Java and Kotlin sources and publish Javadoc JAR files in addition to AARs for library projects. The Javadoc is added to the POM and Gradle Module Metadata files. Enable this feature by adding withJavadocJar() in the singleVariant or multipleVariants publishing block. To learn more, see the publishing options code sample.

Publish sources JAR

AGP 7.1.0 and higher allows you to publish Java and Kotlin source JAR files in addition to AARs for library projects. The sources are added to the POM and Gradle Module Metadata files. You can enable this feature by adding withSourcesJar() in the singleVariant or multipleVariants publishing block. To learn more, see the publishing options code sample.