Past releases

Stay organized with collections Save and categorize content based on your preferences.

This page lists the new features and improvements for each major release of past Android Studio and Android Gradle plugin releases. To see what's new in the latest version, see the current Android Studio release notes and AGP release notes.

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

Android Gradle plugin and Android Studio compatibility

The Android Studio build system is based on Gradle, and the Android Gradle plugin adds several features that are specific to building Android apps. The following table lists which version of the Android Gradle plugin is required for each version of Android Studio.

Android Studio version Required plugin version
Flamingo | 2022.2.1 3.2-8.0
Electric Eel | 2022.1.1 3.2-7.4
Dolphin | 2021.3.1 3.2-7.3
Chipmunk | 2021.2.1 3.2-7.2
Bumblebee | 2021.1.1 3.2-7.1
Arctic Fox | 2020.3.1 3.1-7.0

For information on what’s new in the Android Gradle plugin, see the Android Gradle plugin release notes.

Past releases of Android Studio

Android Studio Chipmunk | 2021.2.1

Support for creating your app with Jetpack Compose

Animation Preview supports 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.

Support for deploying preview from Library Modules

Previews allow you to view your UI within Android Studio without having to run your app on a physical device. In Android Studio Chipmunk, you can deploy a specific @Preview to an emulator or physical device from Library Modules. To learn more, see Deploy Preview.

Support for profiling your app

Detect jank on Android 12 and higher

For devices using Android 12 or higher, a captured trace is shown in the Janky frames track under the Display pane in the CPU Profiler.

To detect jank,

  1. From the development emulator or device, start the app.
  2. In Android Studio, select View > Tool Windows > Profiler or click Profile in the toolbar.

If prompted by the Select Deployment Target dialog, choose the device to which to deploy your app for profiling. If you've connected a device over USB but don't see it listed, ensure that you have enabled USB debugging.

  1. Click anywhere in the CPU timeline to open the CPU Profiler.
  2. You should see the Janky frames track under Display. By default, the Profiler only shows janky frames as candidates for investigation. Within each janky frame, the red portion highlights the duration the frame takes past its rendering deadline. Screenshot of the Janky frames track
  3. Once you find a janky frame, click on it; optionally, you can press M to adjust the zoom to focus on the selected frame. The relevant events are highlighted in the main threads: RenderThread and GPU completion. Screenshot of Profiler displaying Janky frames and main threads
  4. You can optionally see all frames or a breakdown of the rendering time by toggling the checkboxes All Frames and Lifecycle, respectively. Screenshot of Profiler as above but with All Frames and Lifecycle checkboxes checked

For more information, see UI jank detection.

Patch releases

The following is list of patch releases in Android Studio Chipmunk.

Android Studio Chipmunk | 2021.2.1 Patch 2 (August 2022)

This minor update includes the following update and bug fixes:

Android platform support

With Android Studio Chipmunk Patch 2 and Android Gradle 7.2.2, you can compile against Android 13 APIs by setting compileSdk=33. The highest supported minimum SDK version is 32. minSdk = 33 is not supported until Android Gradle plugin 7.3.0-beta05.

Fixed Issues
C++ Debugger
Release version of a native library from a dependent project gets packaged even for a debug build variant
Design Tools
Ctrl + D or “show diff” button doesn't show git diff
Dexer (D8)
Document the compiler version required for each desugared library version
Gradle
Lint UnusedResources False Positive with Import Alias
Import/Sync
Build problem with multiple product flavours in new version
Shrinker (R8)
ArrayIndexOutOfBoundsException in IntSwitch
R8 3.1.7-dev and above improperly optimizes Enums, leading to NoSuchFieldError
R8 causing VerifyError on Scala libraries
Gradle 7.2.0 causing APK build error com.android.tools.r8.CompilationFailedException
NPE in shrinker, R8 version 3.2.60
[R8 3.3.57] NoClassDefFound due to interface replaced with abstract class with higher SDK requirements
NullPointerException in FieldAssignmentTracker using 3.3.35
Android Studio Chipmunk | 2021.2.1 Patch 1 (May 2022)

This minor update includes the following bug fixes:

Fixed Issues
Dexer (D8)
Art / Dalvik VMs prior to version 8 does not support the fix for JDK-8272564
IntelliJ
File watcher failed to start on Ubuntu 20.04
MBP 15" 2018 Touch Bar menu is missed.
Run
Devices option is not visible and unable to run the app even though app module is available.
Shrinker (R8)
Why does R8 doesn't backport default interface methods but D8 does?
CIRCULAR REFERENCE: com.android.tools.r8.internal.R10: Unexpected type in conversion to primitive: OBJECT

Android Studio Bumblebee | 2021.1.1

Android Studio Bumblebee is a major release that includes the following features and improvements.

Compose interactive preview enabled by default

Starting with Android Studio Bumblebee, the interactive preview feature is enabled by default. The interactive preview allows you to interact with a preview as it would work on a device. The interactive preview is isolated from other preview in a sandbox environment, where you can click elements and enter user input in the preview. It’s a quick way to test different states and gestures of your composable, like a checkbox being checked or empty.

Preview interactive mode runs directly inside Android Studio without an emulator running, which results in some limitations:

  • No network access.
  • No file access.
  • Some Context APIs may not be fully available.

User interacting with a preview inside Android Studio

Animated Vector Drawable (AVD) preview

The Animated Vector Drawable tool offers the ability to preview animated drawable resources. This tools helps you preview <animation-list>, <animated-vector>, and <animated-selector> resources in Android Studio and makes it easier to refine your custom animations.

User previewing and playing an animation inside Android Studio

Updated device picker for design tools

To simplify designing your app for the diverse number of Android devices, we’ve updated the device picker in various design tool windows, such as Layout Editor and Layout Validation, with reference devices that reflect popular sizes of each device form factor. From phones to tablets, and Wear devices to Android TVs, it’s now easier to preview, validate, or edit your layout on screen sizes that are most representative of popular real-world devices.

Device picker with devices and their size and density, grouped by class

KMP test execution

You can run tests for Kotlin Multiplatform (KMP) projects from Android Studio Bumblebee.

In order to ensure that your tests run successfully from Android Studio, you must have all of the requirements below:

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

Non-transitive R classes on by default

Non-transitive R classes are now on by default. You can use non-transitive R classes with the Android Gradle plugin to build faster builds for applications with multiple modules. Doing so helps prevent resource duplication by ensuring that each module’s R class only contains references to its own resources, without pulling references from its dependencies. This leads to more up-to-date builds and the corresponding benefits of compilation avoidance.

You can get help using this feature by going to Refactor > Migrate to Non-Transitive R Classes...

Apple Silicon support update

For those using macOS on Apple Silicon (arm64) hardware, Android Studio Arctic Fox and the Android Emulator have supported this new architecture since last year. However, with this release, we have now updated the Android SDK platform tools v32.0.0 (which includes adb and fastboot) and build tools v32.1.0 (which includes aapt) to be universal binaries so that your Android developer tools no longer need the Rosetta binary translator to run. See the SDK platform tools release notes.

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

Layout inspector snapshot for the Sunflower sample app

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.

Semantic information displayed via the Layout Inspector

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>
    3. Deploy your app to the device and connect the Layout Inspector. Android Studio checks whether the flag is set and avoids restarting the Activity, if possible.

Note: While typically not noticeable, setting this device flag when not using the Layout Inspector might affect the app’s performance.

Document Layout Inspector snapshots

You can now capture snapshots of your app’s layout hierarchy to save, share, or inspect 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. When inspecting the layout of a live running app, click Export snapshot Export icon from the Layout Inspector toolbar and save the snapshot 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. The snapshot appears in a tab in the Editor window, so that you can easily compare it with your running app.

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.

Background Task Inspector showing Jobs, Alarms, and Wakelocks

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.

Wireless debugging

Android Studio Bumblebee supports the wireless debugging feature on Android 11 and higher devices. Pair and deploy your app from Android Studio over Wi-Fi without using a USB cable or managing Android Debug Bridge (adb) connections using the command line. To use, navigate to the Pair devices using Wi-Fi option from the device selection menu, and then either choose a QR code or Pairing PIN Code. Then on your Android 11 and higher device, under Developer options, and find the Wireless Debugging screen and initialize and connect to an adb session wirelessly with Android Studio. Learn more about the wireless debugging setup at Connect to a device over Wi-Fi (Android 11+).

Pairing a device over Wi-Fi

Unified Gradle test runner

Android Gradle plugin 7.1.0 and Android Studio Bumblebee and higher use Gradle’s own implementation of the Android instrumented test runner to run instrumented tests. By using the same test runner, results are likely to be consistent whether you run using AGP from the command line, such as on a continuous integration server, or from Android Studio.

Unified Gradle test runner in Bumblebee

Previous versions of Android Studio use the IntelliJ Android instrumented test runner instead of Gradle's Android instrumented test runner. So if you're not using the latest version of Android Studio, depending on whether you run your tests from Android Studio or from the command line using the Gradle plugin, you might see different test results, such as tests passing using one runner and failing on another.

Discrete test runners in older versions of Android Studio

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

Run tests from gutter action

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

The Android Emulator runs directly inside Android Studio by default. This allows you to conserve screen real estate, navigate quickly between the emulator and the editor window using hotkeys, and organize your IDE and emulator workflow in a single application window.

The emulator launching in a tool window in 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 (Android Studio > Preferences > Tools > Emulator on macOS) 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.

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 experiencing, please report a bug.

New Device Manager

New Device Manager window with "pair device" menu option highlighted

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 it easier for you 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.

UI jank detection

When profiling your app using devices running Android 11 (API level 30) or higher, the CPU profiler now shows a new group of tracks that illustrate the stages of each frame under Frame Lifecycle: Application, Wait for GPU, Composition and Frames on display. Each track labels the frames with a frame number and color-codes the rectangle to make it easy for you to visualize where a particular frame is in its lifecycle, along with guides you can toggle to compare with Vsync events. You can use this data to understand where jank might occur in your app and investigate the root causes. In the Analysis panel, there is now a Frames tab, which conveniently summarizes rendering information for all frames. For more information, see UI jank detection.

Profileable app profiling support

When profiling your app, it's important to generate accurate data with the version of your app that most closely resembles what your users will install. To do so, you can now include the <profileable> property in your app's manifest to profile apps that are not debuggable, as shown by the following code.

<profileable android:shell="true"/>

Profileable is a manifest configuration introduced in Android 10, and is available for CPU and Memory profiling tasks. Using the profileable flag instead of the debuggable flag has the key advantage of lower overhead for performance measurement; however, certain profiling features are not available for Profileable builds, such as the Event timeline, API initiated CPU profiling, heap dumps, or live location recordings. For more information, see Profileable applications.

Collapse callstack frames

You can now collapse frames that are irrelevant to your investigation when inspecting a Callstack Sample Recording in the Profilers tool window. Callstacks are useful to understand which part of the code has been executed, and why it was invoked. However, the callstack for a Java/Kotlin program usually includes not only Java/Kotlin code, but also frames from native code that can be distracting. To learn more about refining the callstack view, see Inspect callstack frames.

Patch releases

The following is a list of the Patch releases in Android Studio Bumblebee.

Android Studio Bumblebee | 2021.1.1 Patch 3 (April 2022)

This minor update includes the following bug fixes:

  • Android Gradle plugin
    • Duplicate class issues reported by R8
  • Build Variants
    • versionNameSuffix no longer works if the variant's version name is set via the new onVariants API
  • Compose Preview
    • Performance and stability related bug fixes.
    • Solve freeze that occurred occasionally when using the Live Edit of Literals feature.
  • Network Inspector
    • New Network inspector crashes after Bumblebee update
    • I am constantly getting this error when the debugger is connected on the latest version of Android Studio.
    • TrackedHttpURLConnection.getHeaderField crashes with NullPointerException

For more information, see the Android Studio Bumblebee Patch 3 blog post.

Android Studio Bumblebee | 2021.1.1 Patch 2 (February 2022)

This update includes the following bug fixes:

  • C++ Build
    • ModelCache.safeGet(androidProjectResult.androidProject::getNdkVersion, "") must not be null
  • Code Editor
    • Bug in Android Studio Live Templates - the className() expression is not resolving the class name
  • D8/R8
    • java.lang.NoSuchMethodError: No static method $jacocoInit
    • Android test coverage broken due to Mockito error
    • Need workaround for broken CAS implementation on API 31
    • Sealed classes are not supported
    • NullPointerException when enabling horizontal class merging in Chrome
    • AbstractMethodError after virtual method merging
    • Failure to verify stack frames due to incorrect init-class out-type
    • Dex input uses a register that is not defined
    • StringBuilderOptimizerAnalysisTest is failing on release branches
    • Non-determinism in R8
  • Deployment
    • Running the project of a device owner application fails with "Couldn't terminate the existing process for" error message
  • Design Tools
    • Compose Previews fail to find resources from other modules when non-transitive R classes is enabled
    • Studio freezes on build.
  • Embedded Emulator
    • Miscellaneous performance and stability improvements.
  • Import/Sync
    • IDE error when launching Bumblebee: Output listing build file is not available for output type Apk in IdeBuildTasksAndOutputInformationImp
  • IntelliJ
    • Env variables not sourced when launched from Mac OS X Monterey Dock
  • Jetpack (androidx) > Navigation
    • Upgrade SafeArgs to be built on latest stable AGP
  • Tools Windows
    • Can't run Android Device Manager
    • Network Inspector in BumbleBee doesn't show the api response in readable format

For more information, see the Android Studio Bumblebee Patch 2 blog post.

Android Studio Bumblebee | 2021.1.1 Patch 1 (February 2022)

This minor update includes the following bug fixes:

  • Emulator
    • Unable to connect to embedded emulator after upgrading to Bumblebee (Mac M1)
  • IntelliJ
    • Env variables not sourced when launched from Mac OS X Monterey Dock

For more information, see the Android Studio Bumblebee Patch 1 blog post.

Android Studio Arctic Fox | 2020.3.1

Android Studio Arctic Fox is a major release that includes the following features and improvements.

Android Studio Arctic Fox | 2020.3.1 Patch 4 (December 2021)

This minor update includes the following bug fixes:

  • Android Gradle Plugin
    • Setting a Providerfor VariantOutput.verison can break with configuration cache
    • gradeResValues.xml not updated on signing for release
  • D8/R8
    • java.lang.ClassCastException thrown in class' constructor in build minified by R8
    • Unreachable type adjustment during dex merging
    • java.lang.VerifyError: Verifier failed to verify because instance field cannot be accessed from object of type Reference.java.lang.Object
  • Lint
    • Disable MediaCapabilities lint check
    • Lint reports false positive [Instantiable] error when shrinkResources is enabled
  • Templates
    • Import Module option grayed out

For more information, see the 2020.3.1 Patch 4 blog post.

Android Studio Arctic Fox | 2020.3.1 Patch 3 (October 2021)

This minor update includes the following bug fixes:

  • Android Gradle Plugin
    • lint standalone plugin doesn't handle gradleApi() dependency properly
    • JPS build triggered while Gradle build runs outside of Studio
    • Enabling both KSP and Kapt in a project with both containing processors that generate sources breaks BundleLibraryClassesInputs
  • C++ Editor
    • UI freezes due to long JniReferencesSearch computation in background
  • Database Inspector
    • Allow saving DBs
    • Unable to export data using App Inspection/Database Inspector with blank space in path
  • Dexer (D8)
    • Java lambdas cause unexpected behavior when subclassing subclasses
  • Shrinker (R8)
    • Cannot constrain type error during r8 minification
    • Issue while executing R8 3.0.69 (from AGP 7.0.2) and 3.0.72

For more information, see the 2020.3.1 Patch 3 blog post.

Android Studio Arctic Fox | 2020.3.1 Patch 2 (September 2021)

This minor update includes the following bug fixes:

  • Android Gradle Plugin
    • Gradle sync launched 10 TIMES on upgrade from AS Arctic Fox Canary 7 to Canary 8
    • Desugaring and reproducible builds
  • C++ Build
    • Android Gradle Plugin 7.0.0 does not include jniLibs in APK if tasks.whenTaskAdded closure is used
  • Editing
    • MergedManifestRefreshListener gets stuck in an infinite loop in Arctic Fox
  • Lint
    • "Lint check for lint checks" not running
  • Shrinker (R8)
    • ClassNotFoundException when running build with R8 in AGP7

For more information, see the 2020.3.1 Patch 2 blog post.

Android Studio Arctic Fox | 2020.3.1 Patch 1 (August 2021)

This update includes fixes for the following issues:

  • Android Gradle Plugin
    • TypedefRemover uses ASM5 and is incompatible with JDK 11 sources that require ASM7
    • Some new DSL blocks can't be used from Groovy DSL in AGP 7.0.0
    • AGP 7.0.0 stable throws an ExternalApiUsageException on libraryVariants.all{applicationId}
  • C++ Debugger
    • AS Arctic Fox Error while starting native debug session on Mac M1, "Found broken LLDB configuration"
  • Resource Manager
    • (Windows) New > Vector Asset > picture.svg: invalid 'minus' character in generated xml
  • Shrinker (R8)
    • NPE in BridgeHoisting
    • After upgrade to 7.0.0, R8 crashes with "Unexpected usage left in method after inline" error

For more information, see the 2020.3.1 Patch 1 blog post.

New version numbering

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 that Android Studio is based on.

In the previous numbering system, this release would have been numbered as 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, or version 2020.3.1.

Intellij Version Old Name Old - Number System New - Year System New Version Name
2020.3 4.3 4.3.0 2020.3.1 Arctic Fox | 2020.3.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, it'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 have changed the version numbering for Android Gradle plugin (AGP) to more closely match the underlying Gradle build tool. Therefore, AGP 7.0 is the next release after AGP 4.2.

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

Android Gradle plugin 7.0.0

The latest version of the Android Gradle plugin includes many updates. To learn more, read the full Android Gradle plugin release notes.

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

Context menu for running 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:

Edit test configurations in Android Studio

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>
            

New Background Task Inspector

You can visualize, monitor, and debug your app's background workers using the new Background Task Inspector. To get started, deploy your app to a device running WorkManager library 2.5.0 or higher, and select View > Tool Windows > App Inspection from the menu bar.

Active workers in Background Task Inspector

You can view more detailed information by clicking on a worker. For example, you can see the description of the worker, how it was executed, details of its worker chain, and the result of the execution.

Worker Details tab

You can also view a visual representation of a worker chain by selecting a worker from the table and clicking Show Graph View Graph View button 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 Show List View button.

Background Task Inspector worker chain

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 Cancel Selected Worker button from the toolbar. You can also filter workers in the table by tags you’ve assigned to them using the All tags dropdown menu.

Updates Database Inspector

The Database Inspector is now included in the new App Inspection tool window, where you can also find the new Background Task Inspector. Open the App Inspection tool window from the tool window bar, or select View > Tool Windows > App Inspection from the menu bar.

Export data from the Database Inspector

In Arctic Fox, you can 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 use 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 t option of exporting the data in one or more of the following formats: DB, SQL, or CSV.

Export Database dialog box

Updated UI for recording in Memory Profiler

We have consolidated the Memory Profiler user interface (UI) for different recording activities, such as capturing a heap dump and recording Java, Kotlin, and native memory allocations.

Memory allocations displayed in the Memory Profiler

The Memory Profiler provides the following options:

  • Capture heap dump: View objects in your app that are using memory at a specific point in time.
  • Record native allocations: View how each C/C++ object was allocated over a period of time.
  • Record Java/Kotlin allocations: View how each Java/Kotlin object was allocated over a period of time.

Here's how to use these three options:

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

    Sample heap dump in Memory Profiler

  • To record native allocations on devices running Android 10 and higher, select Record native allocations, then select 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 select 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 (for example, to change the selection range). To complete the recording, select Stop .

    Visualization of Java allocations in Memory Profiler

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

Updates to Refresh Linked C++ Project

We have moved files unrelated to configuration from the .cxx/ folder into the build/ folder. CMake C++ builds require a configuration phase that generates the Ninja project that's used to execute the compile and link steps. Projects generated by CMake are expensive to generate and are expected to survive across gradle clean. For this reason, they're stored in a folder called .cxx/, next to the build/ folder. Typically, Android Gradle plugin will notice configuration changes and automatically regenerate the Ninja project. However, not all cases can be detected. When this happens, the "Refresh Linked C++ Project" option can be used to manually regenerate the Ninja project.

New test matrix for multi-device testing

Instrumentation tests can now run across multiple devices in parallel and can be 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.

Instrumentation test panel

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 from the top-center of the IDE).

    Modify device set dialog

  2. Select the target devices and click OK.

    Modify device set dialog

  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.

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, StateFlowsupport is automatically included in the functionality of data binding, including the coroutines dependencies.

To learn more, see Work with observable data objects.

Improved suggested import

We’ve improved the number of libraries that are supported by the suggested import feature and update the index more frequently. Suggested import helps you quickly and easily import certain Google Maven artifacts into both your class and Gradle project. When Android Studio detects unresolved symbols from certain Google libraries, the IDE suggests importing the library into both the class and the project.

Support for configuration cache in Build Analyzer

Build Analyzer now identifies when a project doesn't have configuration cache enabled, and offers it as an optimization. Build Analyzer runs a compatibility assessment to inform you if there are any issues with configuration cache in your project before it gets enabled.

Configuration cache information in Build Analyzer

Improved Upgrade Assistant for AGP

The Upgrade Assistant for Android Gradle plugin now has a persistent tool window with the list of steps that will be completed. Additional information is also presented on the right side of the tool window. If needed, you can also choose a different version of AGP to upgrade to. Clicking on the Refresh button updates the corresponding update steps.

New persistent tool window in the upgrade assistant

Refactoring for non-transitive R classes

You can use non-transitive R classes with the Android Gradle plugin to build faster builds for applications with multiple modules. Doing so helps prevent resource duplication by ensuring that each module’s R class only contains references to its own resources, without pulling references from its dependencies. This leads to more up-to-date builds and the corresponding benefits of compilation avoidance.

You can access this feature by going to Refactor > Migrate to Non-transitive R Classes.

Support for Jetpack Compose tooling {:jetpack-compose-tooling}

We now offer additional support for previewing and testing apps that use Jetpack Compose. For the best experience developing with Jetpack Compose, you should use the latest version of Android Studio Arctic Fox so that you can benefit from smart editor features, such as New Project templates and the ability to immediately preview your Compose UI.

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.

Compose preview UI

Interactive preview

You can use this feature to 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, click the Interactive icon {: alt="Interactive preview icon" .inline-icon}, and the preview will switch modes.

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

Interactive preview UI

Deploy to device

You can use this feature to deploy a snippet of your UI to a device. This helps test small parts of your code in the device without having to start the full application.

Click the Deploy to Device icon {: alt="Deploy to device icon" .inline-icon} next to the @Preview annotation or at the top of the preview, and Android Studio will deploy that @Preview to your connected device or emulator.

Live Edit of literals

We have added Live Edit of literals to help developers using Compose quickly edit literals (strings, numbers, booleans) in their code and see the results immediately without needing to wait for compilation. The goal of this feature is to help increase your productivity by having code changes appear near instantaneously in the previews, emulator, or physical device.

Editing number and stringd update immediately in the preview and on device

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.

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

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.

Layout inspector UI

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 {: alt="Filter icon" .inline-icon} action, which might help reduce the number of nodes shown in the tree to the ones you are likely to want to inspect.

Improved deploy dropdown

The device dropdown now distinguishes between different kinds of errors within your chosen device configuration. Iconography and stylistic changes now differentiate between errors (device selections that result in a broken configuration) and warnings (device selections that may result in unexpected behavior but are still runnable).

In addition, Android Studio will now warn you if you attempt to launch your project to a device that has an error or a warning associated with it.

New Wear OS pairing assistant

The new Wear OS pairing assistant guides developers step-by-step through pairing Wear OS emulators with physical or virtual phones directly in Android Studio. The assistant can help you get the right Wear OS Companion app installed on your phone and set up a connection between the two devices. You can get started by going to the device dropdown > Wear OS Emulator Pairing Assistant.

Demo of the Wear OS pairing assistant

Responsive layout template

Android Studio Arctic Fox now includes a new layout template that adapts to various display dimensions and app resizing, such as phones, foldables, tablets, and split screen modes. When creating a new project or module, select the Responsive Activity template to create a layout with components that dynamically resize.

Responsive layout template in small screen Responsive layout template in mid screen Responsive layout template in large screen

To get started, navigate to File > New, select either New Project or New Module, and select the Responsive Activity template.

Responsive layout template in new project wizard

Known issues for Arctic Fox

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

Patches not working on Windows for v3.6-v4.1

Patches on Windows platform for v3.6-v4.1 to Android Studio Arctic Fox stable may not work.

4.2 (April 2021)

Android Studio 4.2 is a major release that includes a variety of new features and improvements.

4.2.2 (June 2021)

This minor update includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

4.2.1 (May 2021)

This minor update bundles Kotlin plugin 1.5.0 and includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

Android Gradle plugin 4.2.0

The latest version of the Android Gradle plugin includes many updates. To learn more, read the full Android Gradle plugin release notes.

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 in the AGP release notes.

Option to optimize Gradle sync time

To improve Gradle Sync performance, Android Studio skips building the task list during sync. This allows Gradle Sync to complete faster and improves UI responsiveness for very large projects. This option is on by default in Android Studio 4.2. To turn it off, go to File > Settings > Experimental (Preferences > Experimental on a Mac) and uncheck Do not build Gradle task list during Gradle sync.

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.

DB Inspector editor

Additionally, we now provide a history of your previous queries. When you click on the Show query history Show query history button{: .inline-icon} 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.

Run command in query editor

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

Upgrade Assistant for AGP

A new Upgrade Assistant for Android Gradle plugin can help you update the AGP version for your project.

Android Gradle plugin Upgrade Assistant dialog

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.

Preview of changes to be performed by Upgrade Assistant

System Trace: Improved metrics for memory and graphics

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

  • Events Table. Lists all trace events in the currently selected thread.

  • BufferQueue. In the Display section, this new track shows the buffer count of the app's surface BufferQueue (0, 1, or 2) to help you understand the state of image buffers as they move between the Android graphics components.

    System Trace Buffer Queue

  • CPU Frequency. In the CPU cores section, this new track displays CPU frequency by core, indicating how hard each core is working.

    System Trace CPU Frequency

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

    System Trace Process Memory (RSS)

For more details, see Inspect CPU activity with CPU Profiler.

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.

To manually load a snapshot of UI data from your app, first disable the Live updates option. You can then click the Refresh {:.inline-icon} 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.

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 now includes richer 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

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.

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

    Target device dropdown

  2. Select the target devices and click OK.

    Modify device set dialog

  3. Run your app.

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.

To keep feature modules removable, set dist:removable="true" on any module you want to uninstall.

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

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 Apply Code Changes icon or Apply Changes and Restart Activity Apply Changes and Restart Activity icon.

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 Apply Changes and Restart Activity icon.

Updated New Project and New Module wizards

The New Project and New Module wizards have been updated to make it easier to browse, select a template, and input information about the new project or module.

The option to Import .JAR/.AAR Package from the New Module wizard has also been removed. To import a JAR or AAR into your project, use the Project Structure Dialog instead.

Kotlin 1.4.31

Android Studio 4.2 bundles Kotlin 1.4.31. Check out the Kotlin 1.4.0 changelog to review the major changes.

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 with Android Studio 4.2

This section describes known issues that exist in Android Studio 4.2. For a complete list, go to the Known issues page.

Android Studio 4.2.0 generates projects with wrong Kotlin version: "1.5.0-release-764"

If you are using Android Studio 4.2.0 and have upgraded to Kotlin plugin 1.5.0, then new Kotlin projects created by Studio will fail to build due to the following Gradle sync error:

Could not find org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.0-release-764.

As a workaround, replace 1.5.0-release-764 with 1.5.0 in the project's build.gradle files.

Error when using different passwords for key and keystore

Starting with version 4.2, Android Studio now runs on JDK 11. This update causes an underlying behavior change related to signing keys.

When you navigate to Build > Generate Signed Bundle / APK and attempt to configure app signing for an app bundle or an APK, entering different passwords for the key and keystore may result in the following error:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

To work around this issue, enter the same password for both the key and keystore.

Android Studio doesn’t start after installing version 4.2

Studio tries to import previous .vmoptions and sanitize them to work with the garbage collector used by JDK 11. If that process fails, 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\<var>[Local|Roaming]</var>\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

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

Linux

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

If Studio still doesn't start after trying this workaround, see Studio doesn't start after upgrade below.

4.1 (August 2020)

Android Studio 4.1 is a major release that includes a variety of new features and improvements.

4.1.3 (March 2021)

This minor update includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

4.1.2 (January 2021)

This minor update includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

4.1.1 (November 2020)

This minor update includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

New Database Inspector

Inspect, query, and modify your databases in your running app using the new Database Inspector. To get started, deploy your app to a device running API Level 26 or higher, and select View > Tool Windows > Database Inspector from the menu bar.

To learn more, see Debug your database with the Database Inspector.

Run the Android Emulator directly in Android Studio

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

The emulator launching in a tool window in Android Studio.

To learn more, see the Android Emulator documentation.

Use TensorFlow Lite models

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

Supported models

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

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

Import a model file

To import a supported model file, follow these steps:

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

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

Import a TensorFlow Lite model

View model metadata and usage

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

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

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

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

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

Known issues and workarounds

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

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

Native Memory Profiler

The Android Studio Memory Profiler now includes a Native Memory Profiler for apps deployed to physical devices running Android 10 or later. With the Native Memory Profiler, you can record memory allocations and deallocations from native code and inspect cumulative statistics about native objects.

A recording in the Native Memory Profiler

To learn more about the Native Memory Profiler, see Inspect your app's memory usage with Memory Profiler.

Known issues and workarounds

The Native Memory Profiler in Android Studio 4.1 does not work for Android 11 devices. Support for profiling Android 11 devices is currently available in the 4.2 preview release".

As of the initial 4.1 release, app startup profiling 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.

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

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

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

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

    • Aggregate statistics for all occurrences of a specific event, such as an occurrence count and min/max duration.

    • Trace event statistics for the selected occurrence.

    • Data about thread state distribution.

    • Longest-running occurrences of the selected trace event.

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

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

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

Standalone profilers now available

With the new standalone profilers, it's now possible to profile your app without running the full Android Studio IDE.

For instructions on using the standalone profilers, see Run standalone profilers.

Dagger navigation support

IDE gutter actions for navigating to Dagger consumers and providers

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

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

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

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

Animation: Creating a project in Android Studio with new material design properties.

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

  • MDC: Projects depend on com.google.android.material:material in build.gradle. Base app themes use Theme.MaterialComponents.* parents and override updated MDC color and “on” attributes.

  • Color resources: Color resources in colors.xml use literal names (for example, purple_500 instead of colorPrimary).

  • Theme resources: Theme resources are in themes.xml (instead of styles.xml) and use Theme.<var><var> names.

  • Dark theme: Base application themes use DayNight parents and are split between res/values and res/values-night.

  • Theme attributes: Color resources are referenced as theme attributes (for example, ?attr/colorPrimary) in layouts and styles to avoid hard-coded colors.

IntelliJ IDEA 2020.1

The core Android Studio IDE has been updated with improvements from IntelliJ IDEA through the 2020.1 release, including a new Commit window that enables version control operations and a new Zen mode that can be toggled by selecting View > Appearance > Enter Distraction Free Mode.

To learn more about the improvements in version 2020.1, see IDEA 2020.1.

IDE configuration directory changes

The locations of user configuration directories have been changed to the following:

Windows

Syntax: %APPDATA%\Google&lt;product><version>

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

macOS

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

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

Linux

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

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

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

If Studio doesn't restart after an upgrade, you may need to delete the configuration directory from a previous Studio version. See the known issues page for more information.

Kotlin 1.3.72

Android Studio 4.1 bundles Kotlin 1.3.72, which includes a number of fixes to improve Kotlin highlighting, inspections, and code completion. Check out the 1.3.72 Kotlin changelog for details.

Custom view preview

When creating a custom view (for example, by extending the View or Button class), Android Studio now shows you a preview of your custom view. Use the dropdown menu in the toolbar to switch between multiple custom views, or click the buttons to wrap vertically or horizontally to the content.

Preview custom views in the IDE.

Note: If you don’t see your changes in the preview, select Build > Make Project from the menu bar.

Symbolication for native crash reports

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

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

Apply Changes

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

Faster deploy speeds

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

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

Support for additional code changes

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

4.0 (May 2020)

Android Studio 4.0 is a major release that includes a variety of new features and improvements.

4.0.1 (July 2020)

This minor update includes various bug fixes, as well as support for new default settings for Package visibility in Android 11. For more information, see the release notes for Android Gradle plugin 4.0.1.

To see a list of notable bug fixes for this release, read the related post on the Release Updates blog.

4.0 (May 2020)

Important: After updating, you need to restart Android Studio to apply any memory settings migrated from an earlier version of the IDE. For more information, see the Known Issues page.

Android Gradle plugin 4.0.0

The latest version of the Android Gradle plugin includes many updates, such as Java 8 desugaring for older versions of Android and feature-on-feature dependencies. To learn more, read the full Android Gradle plugin release notes.

Additionally, Android Studio now includes new features to help you improve your build performance.

Build Analyzer

When using Android Studio 4.0 with Android Gradle plugin 4.0.0 and higher, the Build Analyzer window helps you understand and diagnose issues with your build process, such as disabled optimizations and improperly configured tasks. To open the Build Analyzer window, proceed as follows:

  1. If you haven’t already done so, build your app by selecting Build > Make Project from the menu bar.
  2. Select View > Tool Windows > Build from the menu bar.
  3. In the Build window, open the Build Analyzer window in one of the following ways:
    • After Android Studio finishes building your project, click the Build Analyzer tab.
    • After Android Studio finishes building your project, click the link in the right side of the Build Output window.

The Build Analyzer window organizes possible build issues in a tree on the left. You can inspect and click on each issue to investigate its details in the panel on the right. When Android Studio analyzes your build, it computes the set of tasks that determined the build’s duration and provides a visualization to help you understand the impact of each of these tasks. You can also get details on warnings by expanding the Warnings node.

Inspect the tasks most responsible for the build's duration.

Inspecting the tasks that determined the build’s duration.

Java 8 library desugaring in D8 and R8

Android Studio now includes support for using a number of Java 8 language APIs without requiring a minimum API level for your app.

Through a process called desugaring, the DEX compiler, D8, in Android Studio 3.0 and higher already provided substantial support for Java 8 language features (such as lambda expressions, default interface methods, try with resources, and more). In Android Studio 4.0, the desugaring engine has been extended to be able to desugar Java language APIs. This means that you can now include standard language APIs that were available only in recent Android releases (such as java.util.streams) in apps that support older versions of Android.

The following set of APIs is supported in this release:

  • Sequential streams (java.util.stream)
  • A subset of java.time
  • java.util.function
  • Recent additions to java.util.{Map,Collection,Comparator}
  • Optionals (java.util.Optional, java.util.OptionalInt and java.util.OptionalDouble) and some other new classes useful with the above APIs
  • Some additions to java.util.concurrent.atomic (new methods on AtomicInteger, AtomicLong and AtomicReference)
  • ConcurrentHashMap (with bug fixes for Android 5.0)

To support these language APIs, D8 compiles a separate library DEX file that contains an implementation of the missing APIs and includes it in your app. The desugaring process rewrites your app’s code to instead use this library at runtime.

To enable support for these language APIs, include the following in your app module’s build.gradle file:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }
  compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

dependencies { coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4' }

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }
  compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled = true
    // Sets Java compatibility to Java 8
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
  }

dependencies { coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4") }

Note that you may also need to include the above code snippet in a library module's build.gradle file if:

  • The library module's instrumented tests use these language APIs (either directly or through the library module or its dependencies). This is so that the missing APIs are provided for your instrumented test APK.

  • You want to run lint on the library module in isolation. This is to help lint recognize valid usages of the language APIs and avoid reporting false warnings.

Feature-on-feature dependencies

In previous versions of the Android Gradle plugin, all feature modules could depend only on the app's base module. When using Android Gradle plugin 4.0.0 and higher, you can now include a feature module that depends on another feature module. That is, a :video feature can depend on the :camera feature, which depends on the base module, as shown in the figure below.

Feature on feature dependencies

Feature module :video depends on feature :camera, which depends on the base :app module.

This means that when your app requests to download a feature module, the app also downloads other feature modules it depends on. After you create feature modules for your app, you can declare a feature-on-feature dependency in the module’s build.gradle file.

For example, the :video module declares a dependency on :camera as follows:


// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation project(':app')
    // Declares that this module also depends on the 'camera' feature module.
    implementation project(':camera')
    ...
}


// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera' feature module.
    implementation(project(":camera"))
    ...
}

Additionally, you should enable the feature-on-feature dependency feature in Android Studio (to support the feature when editing the Run configuration, for example) by clicking Help > Edit Custom VM Options from the menu bar and including the following:

-Drundebug.feature.on.feature=true

Dependencies metadata

When building your app using Android Gradle plugin 4.0.0 and higher, the plugin includes metadata that describes the dependencies that are compiled into your app. When uploading your app, the Play Console inspects this metadata to provide you with the following benefits:

  • Get alerts for known issues with SDKs and dependencies your app uses
  • Receive actionable feedback to resolve those issues

The data is compressed, encrypted by a Google Play signing key, and stored in the signing block of your release app. However, you can inspect the metadata yourself in the local intermediate build files in the following directory: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

If you’d rather not share this information, you can opt-out by including the following in your module’s build.gradle file:

android {
  dependenciesInfo {
    // Disables dependency metadata when building APKs.
    includeInApk = false
    // Disables dependency metadata when building Android App Bundles.
    includeInBundle = false
  }
}

android {
  dependenciesInfo {
    // Disables dependency metadata when building APKs.
    includeInApk = false
    // Disables dependency metadata when building Android App Bundles.
    includeInBundle = false
  }
}

Support for Kotlin DSL script files

The Android Gradle plugin now supports Kotlin DSL build script files *.kts). When used with Android Studio, certain IDE features, such as the Project Structure dialog and build script quick fixes, now also support reading and writing to Kotlin build script files.

CPU Profiler upgrades

Based on your feedback, we've focused our efforts on improving the user experience in the CPU Profiler in two important ways.

First, compared to previous Android Studio releases, error rates for CPU recordings in the CPU Profiler have been reduced significantly.

Second, the CPU Profiler UI has been overhauled to provide a more intuitive workflow. Some notable UI changes include the following:

  • CPU recordings are now separated from the main profiler timeline to allow for easier analysis. Recorded data are organized in groups on the left side of the Profiler window. You can move groups up and down to reorganize the list by clicking the options options icon in profiler  icon in the top-right corner of the window, or by dragging-and-dropping individual items within a group.
  • For easier side-by-side analysis, you can now view all thread activity in the thread activity timeline (including methods, functions, and events). There are several ways to navigate the timeline:
    • To focus on a specific point in time, drag a range in the CPU usage chart on the top left.
    • To zoom in or out, use the mouse wheel while holding down Control (or Command on MacOS). To pan left or right, drag while holding down the spacebar.
    • Alternatively, use the W and A keys for fine-grained zooming in and out, and the S and D keys for fine-grained panning left and right.
  • The tabs for Flame Chart, Top Down, and Bottom Up analyses are now in the righthand column. In the Threads group, threads are automatically expanded for System Trace recordings and collapsed by default for other recording types. Double-click (or press Enter) on thread names to expand or collapse them.
  • The System Trace UI, as shown in the screenshot, also includes improvements:
    • Events are now uniquely colored for easier differentiation.
    • Threads are sorted by the number of trace events within them so that the “busier” threads are ranked higher in the list.
    • You can select one or more threads to see analysis in the right hand column for those selected threads only.
    • Similarly you can select a trace event within any thread to see analysis data for it.

Design tools

This version of Android Studio includes updates to the design tools, such as the Layout Inspector and an all-new Motion Editor.

New Motion Editor

Android Studio now includes a visual design editor for the MotionLayout layout type, making it easier to create and preview animations.

The Motion Editor provides a simple interface for manipulating elements from the MotionLayout library that serves as the foundation for animation in Android apps. In previous releases, creating and altering these elements required manually editing constraints in XML resource files. Now, the Motion Editor can generate this XML for you, with support for start and end states, keyframes, transitions, and timelines.

To learn more about how to use the Motion Editor, see the user guide.

Note:Before using the Motion Editor, be sure to set the ConstraintLayout dependency in your build.gradle file to version 2.0.0-beta3 or higher.

Live Layout Inspector

Debug your layout with an updated Live Layout Inspector that provides complete, real-time insights into your app’s UI while it’s deployed to a device.

To open a Layout Inspector window, go to View > Tools Windows > Layout Inspector. Along with many of the same features of the existing Layout Inspector, the Live Layout Inspector also includes:

  • Dynamic layout hierarchy: Updates as the views on the device change.

    Dynamic layout hierarchy

  • Property values resolution stack Investigate where a resource property value originates in the source code and navigate to its location by following the hyperlinks in the properties pane.

    Property values resolution stack

  • 3D view: See your app’s view hierarchy at runtime with advanced 3D visualization. To use this feature, in the Live Layout Inspector window simply click on the Layout and rotate it.

    Layout inspector: 3D view

You can use the Live Layout Inspector only when deploying your app to a device or emulator running API level 29 or higher. To enable the Live Layout Inspector, go to File > Settings > Experimental and check the box next to Enable Live Layout Inspector Then click the checkbox next to Live updates above the Layout Display.

Layout Validation

Layout Validation is a visual tool for simultaneously previewing layouts on different devices and configurations, helping you detect layout errors and create more accessible apps.

Creating a customized layout preview in the Layout Validation window

You can access this feature by clicking on the Layout Validation tab in the top-right corner of the IDE window:

The Layout Validation tab in Android Studio

In the Layout Validation window, you can select from four different configuration sets, including:

  • Pixel Devices: Preview your app on a selection of Pixel devices.
  • Custom: Preview your app using custom display options such as screen orientation or language.
  • Color Blind: Preview your app using simulations of common types of color blindness.
  • Font Sizes: Preview your app using a variety of font sizes.

To learn more about using Layout Validation, see

Debug Your Layout with Layout Inspector.

Smart editor features for code shrinker rules

Android Studio now provides smart editor features when you open code shrinker rules files for R8, such as syntax highlighting, code completion, and error checking. The editor also integrates with your Android Studio project to provide full symbol completion for all classes, methods, and fields, and includes quick navigation and refactoring.

Smart editor features when editing R8 rules files

Kotlin Android live templates

Android Studio now includes Android live templates for your Kotlin classes. For example, you can now type toast and press the Tab key to quickly insert a Toast. For a full list of available live templates, click File > Settings from the menu bar (or Android Studio > Preferences on macOS) and navigate to Editor > Live Templates.

Fragment wizard and new fragment templates

A New Android Fragment wizard and new fragment templates are now available when you navigate to File > New > Fragment > Gallery or click Create new destination in the Navigation editor.

Expanded camera support in Android emulator

When using the Android 11 image, Android Emulator camera includes the following new features:

  • RAW capture
  • YUV reprocessing
  • Level 3 devices
  • Logical camera support

To learn more about developing for Android 11, see the Android 11 documentation.

clangd now available for C++ code editor

Jetbrains CLion, the technology underpinning Android Studio's C++ language support, now uses an inspection engine based on LLVM clangd and clang-tidy, speeding up C/C++ code completion and providing a more seamless integration with clang-tidy.

Now available in the Android Studio C++ code editor, clangd and clang-tidy are both part of open-source LLVM extra tooling:

  • clangd features code completion, compile error messages in the editor, and go-to-definition navigation.
  • clang-tidy is a C++ linter tool with an extensible framework for diagnosing and fixing typical programming errors.

In prior releases, Android Studio users could use clang-tidy through the NDK; with this change, Android Studio is no longer dependent on the NDK for clang-tidy functionality.

ndk.dir setting in local.properties file is deprecated

The value for ndk.dir should no longer be set in your app's local.properties file, and support for this ndk.dir setting will be removed in a future version. The Android Gradle Plugin sets the NDK version by default, but if you need a specific version of the NDK, you can set android.ndkVersion in build.gradle.

For more information on setting up the NDK, see Install and configure the NDK and CMake.

IntelliJ IDEA 2019.3.3

The core Android Studio IDE has been updated with improvements from IntelliJ IDEA through the 2019.3.3 release.

To learn more about the improvements from other IntelliJ versions that are included cumulatively with version 2019.3.3, see the following pages:

Past releases of Android Gradle plugin

7.2.0 (May 2022)

Android Gradle plugin 7.2.0 is a major release that includes a variety of new features and improvements.

7.2.2 (August 2022)

This minor update corresponds to the release of Android Studio Chipmunk Patch 2 and includes the following bug fixes:

  • Issue #232438924: AndroidGradlePlugin version 7.2 breaks transform API when used along with ASM API
  • Issue #231037948: AGP 7.2.0-rc01 :buildSrc:generatePrecompiledScriptPluginAccessors - shadow/bundletool/com/android/prefs/AndroidLocation$AndroidLocationException
7.2.1 (May 2022)

This minor update corresponds to the release of Android Studio Chipmunk Patch 1 and includes the following bug fixes:

To see the other bug fixes included in this release, see the Android Studio Chipmunk Patch 1 release notes.

Compatibility

Minimum version Default version Notes
Gradle 7.3.3 7.3.3
SDK Build Tools 30.0.3 30.0.3
NDK N/A 21.4.7075529
JDK 11 11

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{:.external} 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
  }
}

Duplicate content roots not supported

Starting with AGP 7.2, you can no longer share the same source directory across multiple source sets. For example, you can't use the same test sources for both unit tests and instrumentation tests. To learn more, see Change the default source sets configurations.

7.1.0 (January 2022)

Android Gradle plugin 7.1.0 is a major release that includes a variety of new features and improvements.

7.1.3 (April 2022)

This minor update includes the following bug fixes:

  • Duplicate class issues reported by R8

To see a complete list of bug fixes included in this release, see the Android Studio Bumblebee Patch 3 blog post.

7.1.2 (February 2022)

This minor update includes the following bug fixes:

  • Android Gradle Plugin 7.1.0-rc01 fails to perform ASM bytecode transformation during unit tests
  • Gradle sync fails with "Unable to load class 'com.android.build.api.extension.AndroidComponentsExtension'."
  • Some new DSL blocks can't be used from Groovy DSL in Android Gradle Plugin 7.0.0
  • AGP 7.1 new publishing API: created javadoc jar does not get signed
  • ClassesDataSourceCache should use latest Asm version
  • Android Studio BumbleBee does not always deploy latest changes

To see a complete list of bug fixes included in this release, see the Android Studio Bumblebee Patch 2 blog post.

7.1.1 (February 2022)

This minor update corresponds to the release of Android Studio Bumblebee Patch 1.

To see a list of bug fixes included in this release, see the Android Studio Bumblebee Patch 1 blog post.

Compatibility

Minimum version Default version Notes
Gradle 7.2 7.2
SDK Build Tools 30.0.3 30.0.3
NDK N/A 21.4.7075529
JDK 11 11

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

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.

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{:.external} 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{:.external} 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.

Lint block semantic change

All lint methods that override the given severity level of an issue—enable, disable/ignore, informational, warning, error, fatal—now respect the order of configuration. For example, setting an issue as fatal in finalizeDsl() now overrides disabling it in the main DSL. For more information, see the lint{} block reference docs and Android build flow and extension points.

AGP APIs that the Navigation Safe Args Gradle plugin depend on have been removed. AGP 7.1 does not work with Navigation Safe Args versions 2.4.0-rc1 or 2.4.0, but will work with versions 2.5.0-alpha01 and 2.4.1. In the meantime, as a workaround, you can use AGP 7.1 with a snapshot build of Navigation Safe Args, Navigation 2.5.0-SNAPSHOT. To use the snapshot build, follow the snapshot instructions with build id #8054565.

In addition, Navigation Safe Args versions 2.4.1 and 2.5.0 will no longer work with AGP 4.2; to use those versions of Safe Args, you must use AGP 7.0 and higher.

Disable automatic component creation

Starting AGP 8.0, automatic component creation will be disabled by default. Currently, AGP 7.1 automatically creates a component for each build variant, which has the same name as the build variant, and an an all component that contains all the build variants. This automatic component creation will be disabled. To transition to the new behavior, you should manually disable automatic component creation by setting android.disableAutomaticComponentCreation to true. For more information, see Use the Maven Publish plugin.

Firebase Performance Monitoring compatibility

AGP 7.1 is incompatible with the Firebase Performance Monitoring Gradle plugin version 1.4.0 and lower. The AGP Upgrade Assistant will not automatically update the plugin to version 1.4.1, so if you are using firebase-perf and wish to upgrade AGP to 7.1, you need to do this particular upgrade manually.

Known issues

This section describes known issues that exist in Android Gradle plugin 7.1.0.

Problems with unit testing an app project that uses the Hilt plugin

The unit test classpath contains the non-instrumented app classes, which means Hilt does not instrument the app classes to handle dependency injection when running unit tests.

This issue will be fixed with 7.1.1 release, see issue #213534628.

7.0.0 (July 2021)

Android Gradle plugin 7.0.0 is a major release that includes a variety of new features and improvements.

7.0.1 (August 2021)

This minor update includes various bug fixes. To see a list of notable bug fixes, read the related post on the Release Updates blog.

Compatibility

Minimum version Default version Notes
Gradle 7.0.2 7.0.2
SDK Build Tools 30.0.2 30.0.2
NDK N/A 21.4.7075529
JDK 11 11

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, you need to use JDK 11 or higher.

When using AGP independent 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.

Note that the SDK Manager and AVD Manager in the deprecated SDK Tools package don't work with JDK 11. To continue to use the SDK Manager and AVD Manager with AGP 7.0 and higher, you need to switch to the new versions of the tools in the current Android SDK Command-Line Tools package.

Variant API stable

The new Variant API is now stable. See the new interfaces in the com.android.build.api.variant package, and examples in the gradle-recipes GitHub project. As part of the new Variant API, we have made available a number of intermediate files, called artifacts, through the Artifacts interface. These artifacts, like the merged manifest, can be safely obtained and customized by using third-party plugins and code.

We will continue extending the Variant API by adding new functionalities and augmenting the number of intermediate artifacts we make available for customization.

Behavior changes for Lint

This section describes multiple Lint behavior changes in Android Gradle plugin 7.0.0.

Improved lint for library dependencies

Running lint with checkDependencies = true is now faster than before. For Android projects consisting of an app with library dependencies, it is recommended to set checkDependencies to true as shown below, and to run lint via ./gradlew :app:lint, which will analyze all dependency modules in parallel and produce a single report including issues from the app and all of its dependencies.

Groovy

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

Kotlin

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}
Lint tasks can now be UP-TO-DATE

If a module's sources and resources have not changed, the lint analysis task for the module does not need to run again. When this happens, the execution of the task appears as "UP-TO-DATE" in the Gradle output. With this change, when running lint on an application module with checkDependencies = true, only modules that have changed will need to run their analysis. As a result, Lint can run even faster.

The Lint report task also does not need to run if its inputs have not changed. A related known issue is that there is no lint text output printed to stdout when the lint task is UP-TO-DATE (issue #191897708).

Running lint on dynamic-feature modules

AGP no longer supports running lint from dynamic-feature modules. Running lint from the corresponding application module will run lint on its dynamic-feature modules and include all issues in the app’s lint report. A related known issue is that when running lint with checkDependencies = true from an app module, dynamic-feature library dependencies aren’t checked unless they’re also app dependencies (issue #191977888).

Running lint on default variant only

Running ./gradlew :app:lint now runs lint for only the default variant. In previous versions of AGP, it would run lint for all variants.

Missing class warnings in R8 shrinker

R8 more precisely and consistently handles 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 reasons to ignore the warning are:

  1. Libraries that are targeting the JVM and the missing class are of 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

For 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. Add the rules to 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 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 property, android.buildCacheDir property, 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, 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 AGP now uses api/implementation configurations internally, some artifacts may be removed from your compile classpath. If you depend on an AGP dependency at compile-time, be sure to add it as an explicit dependency.

Addition of native libraries in a Java resources folder is not supported

Previously, you could add a native library in a Java resources folder, and register the folder using android.sourceSets.main.resources.srcDirs so that the native library would be extracted and added to the final APK. Starting with AGP 7.0, this is not supported and native libraries in a Java resources folder are ignored. Instead, use the DSL method intended for native libraries, android.sourceSets.main.jniLibs.srcDirs. For more information, see how to configure source sets.

Known issues

This section describes known issues that exist in Android Gradle plugin 7.0.0.

Incompatibility with 1.4.x Kotlin Multiplatform plugin

Android Gradle Plugin 7.0.0 is compatible with Kotlin Multiplatform plugin 1.5.0 and higher. Projects that use the Kotlin Multiplatform support need to update to Kotlin 1.5.0 to use Android Gradle Plugin 7.0.0. As a workaround, you can downgrade the Android Gradle plugin to 4.2.x, although this is not recommended.

For more information, see KT-43944.

Missing lint output

There is no lint text output printed to stdout when the lint task is up-to-date (issue #191897708). For more context, see Behavior changes for lint. This issue will be fixed in Android Gradle plugin 7.1.

Not all dynamic-feature library dependencies are lint checked

When running lint with checkDependencies = true from an app module, dynamic-feature library dependencies aren’t checked unless they’re also app dependencies (issue #191977888). As a workaround, the lint task can be run on those libraries. For more context, see Behavior changes for lint.

4.2.0 (March 2021)

Compatibility

  Minimum version Default version Notes
Gradle 6.7.1 N/A To learn more, see updating Gradle.
SDK Build Tools 30.0.2 30.0.2 Install or configure SDK Build Tools.
NDK N/A 21.4.7075529 Install or configure a different version of the NDK.

New features

This version of the Android Gradle plugin includes the following new features.

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
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.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"
  }
}
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. 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
android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}
// build.gradle.kts
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.

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)
    })
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 <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties, etc. For app modules, if the same Gradle property was present in both <var>projectDir</var>/gradle.properties and <var>projectDir</var>/app/gradle.properties, the value from <var>projectDir</var>/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., <var>projectDir</var>/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.

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.

Note: Although we recommend running Gradle with JDK 11, it is possible to change the JDK used to run Gradle in the Project Structure dialog. Changing this setting will only change the JDK used to run Gradle, and will not change the JDK used to run Studio itself.

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.

DEX files uncompressed in APKs when minSdk = 28 or higher

AGP now packages DEX files uncompressed in APKs by default when minSdk = 28 or higher. This causes an increase in APK size, but it results in a smaller installation size on the device, and the download size is roughly the same.

To force AGP to instead package the DEX files compressed, you can add the following to your build.gradle file:

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Use the DSL to package compressed native libraries

We recommend packaging native libraries in uncompressed form, because this results in a smaller app install size, smaller app download size, and faster app loading time for your users. However, if you want the Android Gradle plugin to package compressed native libraries when building your app, set useLegacyPackaging to true in your app's build.gradle file:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

The flag useLegacyPackaging replaces the manifest attribute extractNativeLibs. For more background, see the release note Native libraries packaged uncompressed by default.

4.1.0 (August 2020)

Compatibility

  Minimum version Default version Notes
Gradle 6.5 N/A To learn more, see updating Gradle.
SDK Build Tools 29.0.2 29.0.2 Install or configure SDK Build Tools.
NDK N/A 21.1.6352462 Install or configure a different version of the NDK.

This version of the Android plugin requires the following:

The default NDK version in this release is 21.1.6352462. To install a different NDK version, see Install a specific version of the NDK.

New features

This version of the Android Gradle plugin includes the following new features.

Kotlin Script DSL support

To help improve the editing experience for Kotlin buildscript users, the DSL and APIs of Android Gradle plugin 4.1 are now defined in a set of Kotlin interfaces separately from their implementation classes. This means that:

  • Nullability and mutability are now explicitly declared on Kotlin types.
  • Documentation generated from those interfaces is published in the Kotlin API Reference.
  • The API surface of the Android Gradle Plugin is clearly defined, to make extending Android builds less brittle in the future.

Important: If you have already adopted KTS build scripts or use Kotlin in buildSrc, this may cause source compatibility breakages for certain errors that would have manifest as run-time errors in previous releases.

Collection types that are designed to be mutated in the DSL are now uniformly defined as:

val collection: MutableCollectionType

This means that it is no longer possible to write the following in Kotlin scripts for some collections that previously supported it:

collection = collectionTypeOf(...)

However, mutating the collection is supported uniformly so collection += … and collection.add(...) should now work everywhere.

If you discover any issues when upgrading a project that uses Android Gradle plugin Kotlin APIs and DSL, please report a bug.

Export C/C++ dependencies from AARs

Android Gradle plugin 4.0 added the ability to import Prefab packages in AAR dependencies. In AGP 4.1, it's now possible to export libraries from your external native build in an AAR for an Android Library project.

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

buildFeatures {
    prefabPublishing true
}

prefab {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }

    <var>myotherlibrary</var> {
        headers "src/main/cpp/<var>myotherlibrary</var>/include"
    }
}
buildFeatures {
    prefabPublishing = true
}

prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }

    create("<var>myotherlibrary</var>") {
        headers = "src/main/cpp/<var>myotherlibrary</var>/include"
    }
}

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

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

R8 support for Kotlin metadata

Kotlin uses custom metadata in Java class files to identify Kotlin language constructs. R8 now has support for maintaining and rewriting Kotlin metadata to fully support shrinking of Kotlin libraries and applications using kotlin-reflect.

To keep Kotlin metadata, add the following keep rules:

-keep class kotlin.Metadata { *; }

-keepattributes RuntimeVisibleAnnotations

This will instruct R8 to keep Kotlin metadata for all classes that are directly kept.

For more information, see Shrinking Kotlin libraries and applications using Kotlin reflection with R8{:.external} on Medium.

Assertions in debug builds

When you build the debug version of your app using Android Gradle plugin 4.1.0 and higher, the built-in compiler (D8) will rewrite your app's code to enable assertions at compile time, so you always have assertion checks active.

Behavior changes

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.

The cleanBuildCache task and the android.enableBuildCache and android.buildCacheDir properties are deprecated and will be removed in AGP 7.0. The android.enableBuildCache property currently has no effect, while the android.buildCacheDir property and the cleanBuildCache task will be functional until AGP 7.0 for deleting any existing AGP build cache contents.

App size significantly reduced for apps using code shrinking

Starting with this release, fields from R classes are no longer kept by default, which may result in significant APK size savings for apps that enable code shrinking. This should not result in a behavior change unless you are accessing R classes by reflection, in which case it is necessary to add keep rules for those R classes.

android.namespacedRClass property renamed to android.nonTransitiveRClass

The experimental flag android.namespacedRClass has been renamed to android.nonTransitiveRClass.

Set in the gradle.properties file, this flag enables namespacing of each library's R class so that its R class includes only the resources declared in the library itself and none from the library's dependencies, thereby reducing the size of the R class for that library.

Kotlin DSL: coreLibraryDesugaringEnabled renamed

The Kotlin DSL compile option coreLibraryDesugaringEnabled has been changed to isCoreLibraryDesugaringEnabled. For more information about this flag, see Java 8+ API desugaring support (Android Gradle Plugin 4.0.0+).

Version properties removed from BuildConfig class in library projects

For library projects only, the BuildConfig.VERSION_NAME and BuildConfig.VERSION_CODE properties have been removed from the generated BuildConfig class because these static values did not reflect the final values of the application’s version code and name, and were therefore misleading. Additionally, these values were discarded during manifest merging.

In a future version of Android Gradle plugin, the versionName and versionCode properties will also be removed from the DSL for libraries. Currently, there is no way to automatically access the app version code/name from a library sub-project.

For application modules, there is no change, you can still assign values to versionCode and versionName in the DSL; these values will propagate to the app’s manifest and BuildConfig fields.

Set the NDK path

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


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

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

If you use this property together with the android.ndkVersion property, then this path must contain an NDK version that matches android.ndkVersion.

Library unit test behavior changes

We've changed the behavior of how library unit tests are compiled and run. A library's unit tests are now compiled and run against compile/runtime classes of the library itself, resulting in the unit test consuming the library in the same way external subprojects do. This configuration typically results in better testing.

In some cases library unit tests that use data binding may encounter missing DataBindingComponent or BR classes. Those tests need to be ported to an instrumented test in the androidTest project, since compiling and running against those classes in a unit test may produce incorrect output.

io.fabric Gradle plugin deprecated

The io.fabric Gradle plugin is deprecated and is not compatible with version 4.1 of the Android Gradle plugin. For more information on the deprecated Fabric SDK and migrating to the Firebase Crashlytics SDK, see Upgrade to the Firebase Crashlytics SDK.

4.0.0 (April 2020)

This version of the Android plugin requires the following:

4.0.1 (July 2020)

This minor update supports compatibility with new default settings and features for package visibility in Android 11.

In previous versions of Android, it was possible to view a list of all apps installed on a device. Starting with Android 11 (API level 30), by default apps have access to only a filtered list of installed packages. To see a broader list of apps on the system, you now need to add a <queries> element in your app or library’s Android manifest.

Android Gradle plugin 4.1+ is already compatible with the new <queries> declaration; however, older versions are not compatible. If you add the <queries> element or if you start relying on a library or SDK that supports targeting Android 11, you may encounter manifest merging errors when building your app.

To address this issue, we’re releasing a set of patches for AGP 3.3 and higher. If you’re using an older version of AGP, upgrade to one of the following versions:

If you are using
AGP version...
...upgrade to:
4.0.* 4.0.1
3.6.* 3.6.4
3.5.* 3.5.4
3.4.* 3.4.3
3.3.* 3.3.3

For more information on this new feature, see Package visibility in Android 11.

New features

This version of the Android Gradle plugin includes the following new features.

Support for Android Studio Build Analyzer

The Build Analyzer window helps you understand and diagnose issues with your build process, such as disabled optimizations and improperly configured tasks. This feature is available when you use Android Studio 4.0 and higher with Android Gradle plugin 4.0.0 and higher. You can open the Build Analyzer window from Android Studio as follows:

  1. If you haven't already done so, build your app by selecting Build > Make Project from the menu bar.
  2. Select View > Tool Windows > Build from the menu bar.
  3. In the Build window, open the Build Analyzer window in one of the following ways:
    • After Android Studio finishes building your project, click the Build Analyzer tab.
    • After Android Studio finishes building your project, click the link on the right side of the Build Output window.

The Build Analyzer window organizes possible build issues in a tree on the left. You can inspect and click on each issue to investigate its details in the panel on the right. When Android Studio analyzes your build, it computes the set of tasks that determined the build's duration and provides a visualization to help you understand the impact of each of these tasks. You can also get details on warnings by expanding the Warnings node.

To learn more, read identify build speed regressions.

Java 8 library desugaring in D8 and R8

The Android Gradle plugin now includes support for using a number of Java 8 language APIs without requiring a minimum API level for your app.

Through a process called desugaring, the DEX compiler, D8, in Android Studio 3.0 and higher already provided substantial support for Java 8 language features (such as lambda expressions, default interface methods, try with resources, and more). In Android Studio 4.0, the desugaring engine has been extended to be able to desugar Java language APIs. This means that you can now include standard language APIs that were available only in recent Android releases (such as java.util.streams) in apps that support older versions of Android.

The following set of APIs is supported in this release:

  • Sequential streams (java.util.stream)
  • A subset of java.time
  • java.util.function
  • Recent additions to java.util.{Map,Collection,Comparator}
  • Optionals (java.util.Optional, java.util.OptionalInt and java.util.OptionalDouble) and some other new classes useful with the above APIs
  • Some additions to java.util.concurrent.atomic (new methods on AtomicInteger, AtomicLong and AtomicReference)
  • ConcurrentHashMap (with bug fixes for Android 5.0)

To support these language APIs, D8 compiles a separate library DEX file that contains an implementation of the missing APIs and includes it in your app. The desugaring process rewrites your app's code to instead use this library at runtime.

To enable support for these language APIs, include the following in your app module's build.gradle file:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }

compileOptions { // Flag to enable support for the new language APIs coreLibraryDesugaringEnabled true // Sets Java compatibility to Java 8 sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }

dependencies { coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4' }

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }

compileOptions { // Flag to enable support for the new language APIs isCoreLibraryDesugaringEnabled = true // Sets Java compatibility to Java 8 sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } }

dependencies { coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4") }

Note that you may also need to include the above code snippet in a library module's build.gradle file if

  • The library module's instrumented tests use these language APIs (either directly or through the library module or its dependencies). This is so that the missing APIs are provided for your instrumented test APK.

  • You want to run lint on the library module in isolation. This is to help lint recognize valid usages of the language APIs and avoid reporting false warnings.

New options to enable or disable build features

Android Gradle plugin 4.0.0 introduces a new way to control which build features you want to enable and disable, such as View Binding and Data Binding. When new features are added, they will be disabled, by default. You can then use the buildFeatures block to enable only the features you want, and it helps you optimize the build performance for your project. You can set the options for each module in the module-level build.gradle file, as follows:

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}
android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

You can also specify the default setting for these features across all modules in a project by including one or more of the following in your project’s gradle.properties file, as shown below. Keep in mind, you can still use the buildFeatures block in the module-level build.gradle file to override these project-wide default settings.

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true
Feature-on-feature dependencies

In previous versions of the Android Gradle plugin, all feature modules could depend only on the app's base module. When using Android Gradle plugin 4.0.0, you can now include a feature module that depends on another feature module. That is, a :video feature can depend on the :camera feature, which depends on the base module, as shown in the figure below.

Feature on feature dependencies

Feature module :video depends on feature :camera, which depends on the base :app module.

This means that when your app requests to download a feature module, the app also downloads other feature modules it depends on. After you create feature modules for your app, you can declare a feature-on-feature dependency in the module’s build.gradle file. For example, the :video module declares a dependency on :camera as follows:

// In the build.gradle file of the ':video' module.
dependencies {
  // All feature modules must declare a dependency
  // on the base module.
  implementation project(':app')
  // Declares that this module also depends on the 'camera'
  // feature module.
  implementation project(':camera')
  ...
}
// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

Additionally, you should enable the feature-on-feature dependency feature in Android Studio (to support the feature when editing the Run configuration, for example) by clicking Help > Edit Custom VM Options from the menu bar and including the following:

-Drundebug.feature.on.feature=true
Dependencies metadata

When building your app using Android Gradle plugin 4.0.0 and higher, the plugin includes metadata that describes the dependencies that are compiled into your app. When uploading your app, the Play Console inspects this metadata to provide you with the following benefits:

  • Get alerts for known issues with SDKs and dependencies your app uses
  • Receive actionable feedback to resolve those issues

The data is compressed, encrypted by a Google Play signing key, and stored in the signing block of your release app. However, you can inspect the metadata yourself in the local intermediate build files in the following directory: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

If you’d rather not share this information, you can opt-out by including the following in your module’s build.gradle file:

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}
android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}
Import native libraries from AAR dependencies

You can now import C/C++ libraries from your app's AAR dependencies. When you follow the configuration steps described below, Gradle automatically makes these native libraries available to use with your external native build system, such as CMake. Note that Gradle only makes these libraries available to your build; you must still configure your build scripts to use them.

Libraries are exported using the Prefabpackage format.

Each dependency can expose at most one Prefab package, which comprises one or more modules. A Prefab module is a single library, which could be either a shared, static, or header-only library.

Typically, the package name matches the Maven artifact name and the module name matches the library name, but this is not always true. Because you need to know the package and module name of the libraries, you might need to consult the dependency's documentation to determine what those names are.

Configure your external native build system

To see the steps you need to follow, follow the steps below for the external native build system you plan to use.

Each of your app's AAR dependencies that includes native code exposes an Android.mk file that you need to import into your ndk-build project. You import this file using the import&endash;module command, which searches the paths you specify using the import&endash;add&endash;path property in your ndk-build project. For example, if your application defines libapp.so and it uses curl, you should include the following in your Android.mk file:

  1. For CMake:

    add_library(app SHARED app.cpp)

    # Add these two lines. find_package(curl REQUIRED CONFIG) target_link_libraries(app curl::curl)

  2. For ndk-build:

    include $(CLEAR_VARS)
    LOCAL_MODULE := libapp
    LOCAL_SRC_FILES := app.cpp
    # Link libcurl from the curl AAR.
    LOCAL_SHARED_LIBRARIES := curl
    include $(BUILD_SHARED_LIBRARY)

    # If you don't expect that your project will be built using versions of the NDK # older than r21, you can omit this block. ifneq ($(call ndk-major-at-least,21),true) $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH)) endif

    # Import all modules that are included in the curl AAR. $(call import-module,prefab/curl)

Native dependencies included in an AAR are exposed to your CMake project via the CMAKE_FIND_ROOT_PATH{: .external} variable. This value will be set automatically by Gradle when CMake is invoked, so if your build system modifies this variable, be sure to append rather than assign to it.

Each dependency exposes a config-file package{: .external} to your CMake build, which you import with the find_package{: .external} command. This command searches for config-file packages that match the given package name and version and exposes the targets it defines to be used in your build. For example, if your application defines libapp.so and it uses curl, you should include the following in your CMakeLists.txt file:


add_library(app SHARED app.cpp)

# Add these two lines. find_package(curl REQUIRED CONFIG) target_link_libraries(app curl::curl)

You can now specify #include "curl/curl.h" in app.cpp. When you build your project, your external native build system automatically links libapp.so against libcurl.so and packages libcurl.so in the APK or app bundle. For additional information, refer to the curl prefab sample{:.external}.

Behavior changes

When using this version of the plugin, you might encounter the following changes in behavior.

v1/v2 signing configuration updates

The behavior for app signing configurations in the signingConfig block has changed to the following:

v1 signing
  • If v1SigningEnabled is explicitly enabled, AGP performs v1 app signing.
  • If v1SigningEnabled is explicitly disabled by the user, v1 app signing is not performed.
  • If the user has not explicitly enabled v1 signing, it can be automatically disabled based on minSdk and targetSdk.
v2 signing
  • If v2SigningEnabled is explicitly enabled, AGP performs v2 app signing.
  • If v2SigningEnabled is explicitly disabled by the user, v2 app signing is not performed.
  • If the user has not explicitly enabled v2 signing, it can be automatically disabled based on targetSdk.

These changes allow AGP to optimize builds by disabling the signing mechanism based on whether the user has explicitly enabled these flags. Prior to this release, it was possible for v1Signing to be disabled even when explicitly enabled, which could be confusing.

feature and instantapp Android Gradle plugins removed

Android Gradle plugin 3.6.0 deprecated the Feature plugin (com.android.feature) and the Instant App plugin (com.android.instantapp) in favor of using the Dynamic Feature plugin (com.android.dynamic-feature) to build and package your instant apps using Android App Bundles.

In Android Gradle plugin 4.0.0 and higher, these deprecated plugins are fully removed. So, to use the latest Android Gradle plugin, you need to migrate your instant app to support Android App Bundles. By migrating your instant apps, you can leverage the benefits of app bundles and simplify your app's modular design.

Note: To open projects that use the removed plugins in Android Studio 4.0 and higher, the project must use Android Gradle plugin 3.6.0 or lower.

Separate annotation processing feature removed

The ability to separate annotation processing into a dedicated task has been removed. This option was used to maintain incremental Java compilation when non-incremental annotation processors are used in Java-only projects; it was enabled by setting android.enableSeparateAnnotationProcessing to true in the gradle.properties file, which no longer works.

Instead, you should migrate to using incremental annotation processors to improve build performance.

includeCompileClasspath is deprecated

The Android Gradle plugin no longer checks for or includes annotation processors you declare on the compile classpath, and the annotationProcessorOptions.includeCompileClasspath DSL property no longer has any effect. If you include annotation processors on the compile classpath, you might get the following error:

Error: Annotation processors must be explicitly declared now.

To resolve this issue, you must include annotation processors in your build.gradle files using the annotationProcessor dependency configuration. To learn more, read Add annotation processors.

Automatic packaging of prebuilt dependencies used by CMake

Prior versions of the Android Gradle Plugin required that you explicitly package any prebuilt libraries used by your CMake external native build by using jniLibs. You may have libraries in the src/main/jniLibs directory of your module, or possibly in some other directory configured in your build.gradle file:

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.srcDirs = ['libs']
  }
}
sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.setSrcDirs(listOf("libs"))
  }
}

With Android Gradle Plugin 4.0, the above configuration is no longer necessary and will result in a build failure:

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
  > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
    > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

External native build now automatically packages those libraries, so explicitly packaging the library with jniLibs results in a duplicate. To avoid the build error, move the prebuilt library to a location outside jniLibs or remove the jniLibs configuration from your build.gradle file.

Known issues

This section describes known issues that exist in Android Gradle plugin 4.0.0.

Race condition in Gradle worker mechanism

Changes in Android Gradle plugin 4.0 can trigger a race condition in Gradle when running with &endash;&endash;no&endash;daemon and versions of Gradle 6.3 or lower, causing builds to hang after the build is finished.

This issue will be fixed in Gradle 6.4.

Older releases

For the release notes for Android Studio and Gradle plugin versions 3.6 and lower, see the release notes archive.