Join us for ⁠#Android11: The Beta Launch Show on June 3!

New features in Android Studio Preview

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

Android Studio 4.1 is currently in the Canary and Dev channels, and Android Studio 4.0 is currently in the Beta channel.

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

If you encounter any problems using a preview version of Android Studio, please let us know. Your bug reports help to make Android Studio better.

Android Studio 4.1

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

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

IDE configuration directory changes in Canary 9

In the Canary 9 release, the locations for user configuration directories have been changed to the following:

Windows

Syntax: %APPDATA%\Google\<product><version>

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

macOS

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

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

Linux

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

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

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

Improved instrumentation testing

Starting in Android Studio 4.1 Canary 8, instrumentation tests can now be run across multiple devices in parallel and investigated using a specialized instrumentation test results panel. Using this panel, you can determine if tests are failing due to API level or hardware properties.

Insrumentation 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. Select Modify Device Set 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. Select Multiple Devices in the target device dropdown menu and run your tests.

    Select Multiple Devices from target device dropdown

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.

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.

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 run the emulator in Android Studio, make sure you're using Android Studio 4.1 with version 30.0.10 or higher of the Android Emulator, then follow these steps:

  1. Click File > Settings > Tools > Emulator (or Android Studio > Preferences > Tools > Emulator on macOS), then select Launch in a tool window and click OK.
  2. If the Emulator window didn't automatically appear, open it by clicking View > Tool Windows > Emulator.
  3. Start your virtual device using the AVD Manager or by targeting it when running your app.

Limitations

Currently, you can't use the emulator's extended controls when it's running in a tool window. If your development workflow depends heavily on the extended controls, continue to use the Android Emulator as a standalone application. In addition, certain virtual devices—such as Android TV and foldable devices—can't be run in Android Studio because they have specialized UI requirements or important functions in the extended controls.

Database Inspector

With Android Studio 4.1 Canary 6 and higher, you can inspect, query, and modify your app’s databases using the new Database Inspector. For example, you can debug your running app by modifying values in your database and testing those changes on the device.

Modify table values and see the changes in your running app

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.

If the Database Inspector window doesn’t automatically select your app’s process, select it from the dropdown menu.

Inspect and modify tables

In the Databases panel, you can see the database(s) for your app, and you can expand a database node to see its tables. When you double-click on a table, the inspector opens it in a separate tab on the right, as shown in the screenshot below, where you can inspect its data, sort by columns, or even modify values as your app is running on the device.

To change the value of a table cell, simply double-click into the cell, change its value, and press Enter. If you're using the Room persistence library and observing your databases (such as with LiveData), those changes should be visible in your running app almost immediately. Otherwise, you might need to refresh your app's query of the database to see your changes.

Inspect, query, and modify your app’s databases

If your app makes updates to its database and you want to automatically see those updates in the inspector window, check the box next to Live updates. Keep in mind, while this option is enabled, the table in the inspector becomes read-only and you can not modify its values.

Alternatively, you can manually update the data in the inpector by clicking Refresh Table. Similarly, if there are changes to database schemas, click Refresh Schema in the Databases panel.

Query your database

To query a database, click Open New Query tab in the Databases panel. This opens a New Query tab on the right. If your app includes more than one database, select the database you want to query using the dropdown menu in the tab window. In the text field, you can specify your SQLite query and click Run. The inspector queries your app’s database and returns the result, as shown below.

Query your database

If you use the Room persistence library, Android Studio also provides gutter actions to help you quickly run queries you define in your @Query annotations. While your app is deployed to a compatible device and the Database Inspector is open in the IDE, click the button next to a @Query annotation, as shown below.

Room Query annotation gutter action

The Database Inspector opens a new tab, runs the query, and returns the results. If your query includes named bind parameters, such as :name, Android Studio requests values for each parameter before running the query.

Prevent new and existing databases from closing

If your app frequently connects to and disconnects from databases, it can be difficult to inspect those databases. That's because inspecting, querying, and modifying a database requires that your app maintain a live connection to it. The Database Inspector window uses icons to help you identify open () and closed () databases.

To make it easier to inspect those databases, you can prevent new and existing connections to your databases from closing by clicking Keep database connections open . When this behavior is enabled, the Keep database connections open button changes to .

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 a sample size of 32 bytes, the Native Memory Profiler tracks allocations/deallocations of objects in native code for a specific time period and provides the following information:

  • Allocations: A count of objects allocated via malloc() or the new operator during the selected time period.
  • Deallocations: A count of objects deallocated via free() or the delete operator during the selected time period.
  • Allocations Size: The aggregated size in bytes of all allocations during the selected time period.
  • Deallocations Size: The aggregated size in bytes of all freed memory during the selected time period.
  • Total Count: The value in the Allocations column minus the value in the Deallocations column.
  • Remaining Size: The value in the Allocations Size column minus the value in the Deallocations Size column.

Native Memory Profiler

To initiate a recording, click Record native allocations at the top of the Memory Profiler window:

Record native allocations button

When you're ready to complete the recording, click Stop recording.

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 Canary 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 image classification models are provided on TensorFlow Hub – just look for and download the model formats that mention "metadata". 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 will create 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:

Screenshot of TensorFlow Lite model viewer

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.

Support for Jetpack Compose

Jetpack Compose toolkit provides a modern approach to building your app's UI. The toolkit also brings all of Kotlin's benefits, such as helping you to write concise and idiomatic code that's fully interoperable with Java.

For the best experience developing with Jetpack Compose, you should use the latest version of Android Studio 4.1. That's because when you use Android Studio to develop your app with Jetpack Compose, you can benefit from smart editor features, such as New Project templates and the ability to immediately preview your Compose UI.

To learn more and get started, go to the Jetpack Compose overview.

Assertions in debug builds

Assertions in your Java code are now enabled when deploying the debug version of your app. Because the Android runtime doesn't support enabling assertions at runtime (that is, passing the equivalent of the -ea/-enableassertions flag to a Java VM), assertions in your app previously had no effect.

Now, when you build and deploy the debug version of your app using Android Gradle plugin 4.1.0-alpha01 and higher, the built-in compiler (D8) rewrites the code to enable assertions at compile time, so you always have the assertion checks active.

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 or Apply Changes and Restart Activity 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 static final primitive fields and then deploy those changes to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity .

You can now also add resources and then deploy those changes to your running app on Android 11 devices by clicking Apply Changes and Restart Activity .

Export C/C++ dependencies from AARs

Android Gradle Plugin 4.0 added the ability to import Prefab packages in AAR dependencies as described below. Beginning with canary 10, version 4.1 enables exporting 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 {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/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.

Known Issues for 4.1 Preview

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

Workaround for missing Kotlin plugin in Canary 9

In Android Studio 4.1 Canary 9, you may see the following error when first launching Android Studio after upgrading:

missing essential plugin org.jetbrains.android

This can happen when you import your settings from a previous version of Android Studio. Typically, this means you have a locally installed Kotlin plugin that is not compatible with the new IDE.

To fix this issue, remove the Kotlin directory from the following locations:

Linux: ~/.local/share/Google/AndroidStudioPreview4.1

Windows: C:\Users\YourUserName\AppData\Roaming\Google\AndroidStudioPreview4.1

MacOS: ~/Library/Application Support/Google/AndroidStudioPreview4.1

Because there is no Kotlin plugin compatible with Canary 9 currently available from JetBrains, we have bundled our own Kotlin plugin with the Canary 9 update, so you don't need to manually install a Kotlin plugin.

Patches not working in 4.1 Canary 2

Patches for Android Studio 4.1 Canary 2 are currently broken. To update to a newer version of Android Studio 4.1, shut down Android Studio, then download and install the latest package.

This issue has been fixed in Android Studio 4.1 Canary 3.

Timeout errors in CPU Profiler

You may experience "Recording failed to stop" errors in the Android Studio CPU Profiler when you select the Sample Java Methods or Trace Java Methods configurations. These are often timeout errors, especially if you see the following error message in the idea.log file:

Wait for ART trace file timed out

The timeout errors tend to affect traced methods more than sampled methods and longer recordings more than shorter recordings. As a temporary workaround, it may be helpful to try shorter recordings to see if the error disappears.

If you experience timeout issues with the Profiler, please file a bug that includes the make/model of your device(s) and any relevant entries from idea.log and logcat.

Git version control errors in the IDE

Operations requiring authentication in Git version control are broken in the IDE for Android Studio 4.1 Canary 1.

To fix this issue, upgrade to Android Studio 4.1 Canary 2.

Android Studio 4.0

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

CPU Profiler UI Upgrades

System Trace UI Upgrades

Based on your feedback, the CPU Profiler UI has been overhauled to provide a more intuitive workflow. Notable changes include:

  • 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).
  • 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 on thread names to expand or collapse them.
  • The System Trace UI, as shown in the screenshot above, is also improved. For example, events are now uniquely colored for easier differentiation.

This feature is still a work in progress, so please continue to provide feedback.

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.

Build Speed window

When using Android Studio 4.0 Canary 3 with Android Gradle plugin 4.0.0-alpha03 and higher, the Build Speed window helps you understand and diagnose issues with your build process, such as disabled optimizations and improperly configured tasks. When using Android Studio 4.0 Canary 3 and higher, and Android Gradle plugin 4.0.0-alpha03 and higher, you can open the Build Speed window 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 Speed window in one of the following ways:
    • After Android Studio finishes building your project, click the Build Speed tab.
    • After Android Studio finishes building your project, click the link in the right side of the Build Output window.

The Build Speed 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.

Build speed chart

Which tasks determine build duration?

Gradle determines task execution by task interdependencies, project structure, and CPU load, and executes tasks either sequentially or in parallel. For a given build, the Build Speed window highlights the set of sequentially executed tasks that determined the duration of the current build. Addressing inefficiencies in these highlighted tasks is the best starting point for reducing your overall build time.

Keep in mind, you might see a different set of tasks determining build duration with each build you execute. For example, if you make changes to the build configuration, run a build with a different set of tasks (such as an incremental build), or run a build under different constraints (for example, heavier CPU load), the Build Speed window may highlight a different set of tasks that most impacted that build's duration. Because of this variability, you might want to use the Build Speed window across multiple builds to consistently reduce build duration.

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 devices running API level 29 or higher. You must also enable the feature by navigating to File > Settings > Experimental, and checking the box next to Enable Live Layout Inspector.

Multi Preview

Multi Preview is a visual tool for simultaneously previewing layouts in different devices and configurations, which can help catch potential issues in your layouts.

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

Multi Preview tab

You can select from two different configuration sets: Pixel devices and project locales. To switch between these configuration sets, select from the dropdown menu at the top of the Multi Preview window:

Multi Preview demonstration

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 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.5'
}

Let us know if you run into issues or if there are other APIs you want supported by filing bugs bugs on our bug tracker.

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.

Smart editor features for ProGuard rules

Android Studio now provides smart editor features when you open ProGuard rules files, 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 ProGuard rules files

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 get started with the Motion Editor:

  1. Create a ConstraintLayout.
  2. Right-click on the preview in the Layout Editor.
  3. Click Convert to MotionLayout, as shown below.

After Android Studio converts your ConstraintLayout to MotionLayout, a Motion Scene file is also added to the directory containing your XML.

The MotionLayout then becomes your root layout, and it appears in the Motion Editor UI. The layout already includes a start ConstraintSet, end ConstraintSet, and a transition going from start to end.

You can use the overview graphic to select a ConstraintSet or Transition and to select components on the selection panel.

Then you can edit the constraints and attributes of either the start or end ConstraintSet the same way you would edit a ConstraintLayout.

If you want to build more elements to your graph, you can use the creation icons to quickly add a ConstraintSet, Transition, or OnClick/OnSwipe gestures.

To add a keyframe, first click on the Transition arrow:

Then, in the Transition timeline pane, click on the top-right corner and select KeyPosition:

This action opens a dialog where you can set attributes for the keyframe.

You can also add OnClick and OnSwipe handlers to the Transition in the attribute panel.

This action opens a dialog where you can set attributes of the click such as target components and drag direction.

The Motion Editor supports previewing animations on the design surface. When an animation is selected, click Play above the timeline to preview the animation.

New in Android Gradle plugin 4.0.0

This section describes new features and behavior changes included in Android Gradle plugin 4.0.0.

New options to enable or disable build features

Android Gradle plugin 4.0.0-alpha05 introduces a new way to control which build features you want to enable and disable, such as View Binding, Data Binding, and Jetpack Compose. 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
    }
}

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

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

This means that when your app requests to download a dynamic feature module, the app also downloads other feature modules it depends on. After you create dynamic 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 dynamic feature modules must declare a dependency
    // on the base module.
    implementation project(':app')
    // Declares that this module also depends on the 'camera'
    // dynamic 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

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

Dependencies metadata

When building your app using Android Gradle plugin 4.0.0-beta02 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
    }
}

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.

The Fragment gallery wizard.

The Fragment gallery wizard.

Import native libraries from AAR dependencies

Starting with Android Gradle Plugin 4.0 Canary 9, you can 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 Prefab package 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, click on the external native build system you plan to use.

Native dependencies included in an AAR are exposed to your CMake project via the CMAKE_FIND_ROOT_PATH 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 to your CMake build, which you import with the find_package 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.

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:

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']
    }
}

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, simple remove the jniLibs configuration from your build.gradle file.

Known Issues for 4.0 Preview

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

Build Analyzer Disabled in Beta 4

The Build Analyzer is disabled in Android Studio 4.0 Beta 4. It will be re-enabled in Beta 5.

Timeout Errors in CPU Profiler

You may experience "Recording failed to stop" errors in the Android Studio CPU Profiler when you select the Sample Java Methods or Trace Java Methods configurations. These are often timeout errors, especially if you see the following error message in the idea.log file:

Wait for ART trace file timed out

The timeout errors tend to affect traced methods more than sampled methods and longer recordings more than shorter recordings. As a temporary workaround, it may be helpful to try shorter recordings to see if the error disappears.

If you experience timeout issues with the Profiler, please file a bug that includes the make/model of your device(s) and any relevant entries from idea.log and logcat.

Patches not working in 4.0 Beta 2

Patches for Android Studio 4.0 Beta 2 are currently broken. To update to a newer version of Android Studio 4.0, shut down Android Studio, then download and install the latest package.

This issue is fixed in Android Studio 4.0 Beta 3.

Git version control errors in the IDE

Operations requiring authentication in Git version control are broken in the IDE for Android Studio 4.0 Beta 1.

To fix this issue, upgrade to Android Studio 4.0 Beta 2 or higher.

Missing Run, Debug, and Profile toolbar buttons

If you have customized the Run/Debug group of action buttons—for example, by modifying options under Appearance & Behavior > Menus and Toolbars in the Settings or Preferences window—those action buttons might disappear from the toolbar after you restart the IDE. This is a known issue in the version of IntelliJ that Android Studio 4.0 is built on (see issue IDEA-228450).

To resolve this issue, revert any customizations you have made to those buttons as follows:

  1. Select File > Settings (or Android Studio > Preferences on macOS).
  2. On the left of the window, navigate to Appearance & Behavior > Menus and Toolbars.
  3. On the right side of the window, navigate to Main Toolbar > Toolbar Run Actions and select Run/Debug.
  4. Near the top of the window, click Revert. and select Restore Run/Debug.
  5. Click OK. You should now see the missing buttons in the toolbar.

Patches Not Available for Canary 5

No patches for Android Studio 4.0 Canary 5 are available for previously released Android Studio 4.0 Canary versions. To install Android Studio 4.0 Canary 5, please download it from the Android Studio downloads page.

Profilers and Live Layout Inspector in Canary 5

Starting with Android Studio 4.0 Canary 5, the Live Layout Inspector and the Profilers do not function correctly on Windows, causing the following error message:

transfer error: couldn't create file: Read-only file system.

To fix this issue, upgrade to Android Studio 4.0 Canary 7 or higher.

Missing Kotlin Maven repo

If you are using Android Studio 4.0 Canary 4 or lower, you might see the following error message:

Application build has failed with an error (Could not find org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3.60-eap-25)

To resolve this issue, update to Android Studio 4.0 Canary 5 or higher.