Android Gradle plugin release notes

The Android Studio build system is based on Gradle, and the Android Gradle
plugin adds several features that are specific to building Android
apps. Although the Android plugin is typically updated in lock-step with Android
Studio, the plugin (and the rest of the Gradle system) can run independent of
Android Studio and be updated separately.

This page explains how to keep your Gradle tools up to
date and what's in the recent updates.

For details about how to configure your Android builds with Gradle,
see the following pages:

Update the Android Gradle plugin

When you update Android Studio, you may receive a prompt to automatically
update the Android Gradle plugin to the latest available version. You
can choose to accept the update or manually specify a version based on
your project's build requirements.

You can specify the plugin version in
either the File > Project
Structure > Project menu in Android Studio, or
the top-level build.gradle file. The plugin version applies to
all modules built in that Android Studio project. The following example sets
the plugin to version 4.0.0 from the
build.gradle file:

Caution: You should not use dynamic dependencies in version
numbers, such as 'com.android.tools.build:gradle:2.+'. Using
this feature can cause unexpected version updates and difficulty resolving
version differences.

If the specified plugin version has not been downloaded, Gradle downloads it
the next time you build your project or click Tools >
Android > Sync Project with Gradle Files
from the Android Studio menu bar.

Update Gradle

When you update Android Studio, you may receive a prompt to also
update Gradle to the latest available version. You can choose to accept the
update or manually specify a version based on your project's build
requirements.

The following table lists which version of Gradle is required for each
version of the Android Gradle plugin. For the best performance, you should
use the latest possible version of both Gradle and the plugin.

Plugin version

Required Gradle version

1.0.0 - 1.1.3

2.2.1 - 2.3

1.2.0 - 1.3.1

2.2.1 - 2.9

1.5.0

2.2.1 - 2.13

2.0.0 - 2.1.2

2.10 - 2.13

2.1.3 - 2.2.3

2.14.1+

2.3.0+

3.3+

3.0.0+

4.1+

3.1.0+

4.4+

3.2.0 - 3.2.1

4.6+

3.3.0 - 3.3.2

4.10.1+

3.4.0 - 3.4.1

5.1.1+

3.5.0-3.5.3

5.4.1+

3.6.0-3.6.2

5.6.4+

4.0.0+

6.1.1+

You can specify the Gradle version in either the File >
Project Structure > Project menu in
Android Studio, or by editing the Gradle distribution reference in the
gradle/wrapper/gradle-wrapper.properties file. The following
example sets the Gradle version to 6.1.1 in the
gradle-wrapper.properties file.

4.0.0 (April 2020)

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:

If you haven’t already done so, build your app by selecting Build > Make
Project from the menu bar.

Select View > Tool Windows > Build from the menu bar.

In the Build window, open the Build Analyzer window in one of the
following ways:

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.

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
module’s build.gradle file:

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:

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.

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.

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

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:

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.

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:

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.

Behavior changes

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

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.

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.

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 --no-daemon and versions of Gradle 6.3 or lower, causing
builds to hang after the build is finished.

3.6.0 (February 2020)

New features

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

View Binding

View binding provides compile-time safety when referencing views in your code.
You can now replace findViewById() with the auto-generated binding class
reference. To start using View binding, include the following in each module's
build.gradle file:

Support for the Maven Publish plugin

The Android Gradle plugin includes support for the
Maven Publish Gradle plugin,
which allows you to publish build artifacts to an Apache Maven repository. The
Android Gradle plugin creates a
component
for each build variant artifact in your app or library module that you can use
to customize a
publication
to a Maven repository.

New default packaging tool

When building the debug version of your app, the plugin uses a new
packaging tool, called zipflinger, to build your APK. This new tool should
provide build speed improvements. If the new packaging tool doesn't work as you
expect, please report a bug. You can revert to using the
old packaging tool by including the following in your gradle.properties file:

android.useNewApkCreator=false

Native build attribution

You can now determine the length of time it takes Clang to build and link each
C/C++ file in your project. Gradle can output a Chrome trace that contains
timestamps for these compiler events so you can better understand the time
required to build your project. To output this build attribution file, do the
following:

Add the flag -Pandroid.enableProfileJson=true when running a Gradle
build. For example:

gradlew assembleDebug -Pandroid.enableProfileJson=true

Open the Chrome browser and type chrome://tracing in the search bar.

Click the Load button and navigate to project-root/build/android-profile
to find the file. The file is named profile-timestamp.json.gz.

You can see the native build attribution data near the top of the viewer:

Behavior changes

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

Native libraries packaged uncompressed by default

When you build your app, the plugin now sets extractNativeLibs to "false" by
default. That is, your native libraries are page aligned and packaged
uncompressed. While this results in a larger upload size, your users
benefit from the following:

Smaller app install size because the platform can access the native libraries
directly from the installed APK, without creating a copy of the libraries.

Smaller download size because Play Store compression is typically better when
you include uncompressed native libraries in your APK or Android App Bundle.

If you want the Android Gradle plugin to instead package compressed native
libraries, include the following in your app's manifest:

<application
android:extractNativeLibs="true"
... >
</application>

Default NDK version

If you download multiple versions of the NDK, the Android Gradle plugin now
selects a default version to use in compiling your source code files. Previously,
the plugin selected the latest downloaded version of the NDK. Use the
android.ndkVersion property in the module's build.gradle file to override
the plugin-selected default.

Simplified R class generation

The Android Gradle plugin simplifies the compile classpath by generating only
one R class for each library module in your project and sharing those R classes
with other module dependencies. This optimization should result in faster
builds, but it requires that you keep the following in mind:

Because the compiler shares R classes with upstream module dependencies, it’s
important that each module in your project uses a unique package name.

The visibility of a library's R class to other project dependencies is
determined by the configuration used to include the library as a dependency.
For example, if Library A includes Library B as an 'api' dependency, Library
A and other libraries that depend on Library A have access to Library B's R
class. However, other libraries might not have access to Library B's R class
If Library A uses the implementation dependency configuration. To learn
more, read about dependency
configurations.

Remove resources missing from default configuration

For Library modules, if you include a resource for a language that you do not
include in the default set of resources—for example, if you include
hello_world as a string resource in /values-es/strings.xml but you don’t
define that resource in /values/strings.xml—the Android Gradle plugin no
longer includes that resource when compiling your project. This behavior change
should result in fewer Resource Not Found runtime exceptions and improved
build speed.

D8 now respects CLASS retention policy for annotations

When compiling your app, D8 now respects when annotations apply a CLASS
retention policy, and those annotations are no longer available at runtime. This
behavior also exists when setting the app’s target SDK to API level 23, which
previously allowed access to these annotations during runtime when compiling
your app using older versions of the Android Gradle plugin and D8.

Other behavior changes

aaptOptions.noCompress is no longer case sensitive on all platforms (for
both APK and bundles) and respects paths that use uppercase characters.

Data binding is now incremental by default. To learn more, see
issue #110061530.

All unit tests, including Roboelectric unit tests, are now fully
cacheable. To learn more, see
issue #115873047.

Bug fixes

This version of the Android Gradle plugin includes the following bug fixes:

Robolectric unit tests are now supported in library modules that use data
binding. To learn more, see
issue #126775542.

You can now run connectedAndroidTest tasks across multiple modules while
Gradle's parallel execution
mode is enabled.

Known issues

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

Slow performance of Android Lint task

Android Lint can take much longer to complete on some projects due to a
regression in its parsing infrastructure, resulting in slower computation of
inferred types for lambdas in certain code constructs.

The issue is reported as a bug in IDEA
and will be fixed in Android Gradle Plugin 4.0.

Missing Manifest class

If your app defines custom permissions in its manifest, the Android Gradle
plugin typically generates a Manifest.java class that includes your custom
permissions as string constants. The plugin packages this class with your app,
so you can more easily reference those permissions at runtime.

Generating the manifest class is broken in Android Gradle plugin 3.6.0. If you
build your app with this version of the plugin, and it references the manifest
class, you might see a ClassNotFoundException exception. To resolve this
issue, do one of the following:

public final class CustomPermissions {
public static final class permission {
public static final String DEADLY_ACTIVITY="com.example.myapp.permission.DEADLY_ACTIVITY";
}

3.5.0 (August 2019)

Android Gradle plugin 3.5.0, along with Android Studio
3.5, is a major release and a result of Project Marble,
which is a focus on improving three main areas of the Android developer tools:
system health, feature polish, and fixing bugs. Notably, improving project
build speed
was a main focus for this update.

Additionally, KAPT 1.3.30 and higher also support incremental annotation
processors, which you can enable by including kapt.incremental.apt=true in
your gradle.properties file.

Cacheable unit tests

When you enable unit tests to use Android resources, assets, and manifests by
setting includeAndroidResources
to true, the Android Gradle plugin generates a test config file
containing absolute paths, which breaks cache relocatability. You can instruct
the plugin to instead generate the test config using relative paths, which
allows the AndroidUnitTest task to be fully cacheable, by including the
following in your gradle.properties file:

android.testConfig.useRelativePath = true

Known issues

When using Kotlin Gradle plugin 1.3.31 or earlier, you might see the following
warning when building or syncing your project:

WARNING: API 'variant.getPackageLibrary()' is obsolete and has been replaced
with 'variant.getPackageLibraryProvider()'.

To resolve this issue,
upgrade the plugin to version 1.3.40 or higher.

This minor update supports Android Studio 3.4.2 and includes various bug
fixes and performance improvements.
To see a list of noteable bug fixes, read the related post on the
Release Updates blog.

3.4.1 (May 2019)

This minor update supports Android Studio 3.4.1 and includes various bug
fixes and performance improvements.
To see a list of noteable bug fixes, read the related post on the
Release Updates blog.

New features

New lint check dependency configurations: The behavior of lintChecks has
changed and a new dependency configuration, lintPublish, has been introduced
to give you more control over which lint checks are packaged in your Android
libraries.

lintChecks: This is an existing configuration that you should use for
lint checks you want to only run when building your project locally. If you
were previously using the lintChecks dependency configuration to include
lint checks in the published AAR, you need to migrate those dependencies to
instead use the new lintPublish configuration described below.

lintPublish: Use this new configuration in library projects for lint checks
you want to include in the published AAR, as shown below. This means that
projects that consume your library also apply those lint checks.

The following code sample uses both dependency configurations in a local
Android library project.

In general, packaging and signing tasks should see an overall build speed
improvement. If you notice a performance regression related to these tasks,
please report a bug.

Behavior changes

Android Instant Apps Feature plugin deprecation warning: If you’re still
using the com.android.feature plugin to build your instant app, Android
Gradle plugin 3.4.0 will give throw you a deprecation warning. To make sure
you can still build you instant app on future versions of the plugin, migrate
your instant app to using
the dynamic feature plugin, which also
allows you to publish both your installed and instant app experiences from a
single Android App Bundle.

R8 enabled by default: R8 integrates desugaring, shrinking, obfuscating,
optimizing, and dexing all in one step—resulting in
noticeable build performance improvements.
R8 was introduced in Android Gradle plugin 3.3.0 and
is now enabled by default for both app and Android library projects using
plugin 3.4.0 and higher.

The image below provides a high-level overview of the compile process
before R8 was introduced.

Now, with R8, desugaring, shrinking, obfuscating, optimizing, and dexing (D8)
are all completed in one step, as illustrated below.

Keep in mind, R8 is designed to work with your existing ProGuard rules, so
you’ll likely not need to take any actions to benefit from R8. However,
because it’s a different technology to ProGuard that’s designed specifically
for Android projects, shrinking and optimization may result in removing code
that ProGuard may have not. So, in this unlikely situation, you might need to
add additional rules to keep that code in your build output.

If you experience issues using R8, read the
R8 compatibility FAQ
to check if there’s a solution to your issue. If a solution isn’t documented,
please report a bug.
You can disable R8 by adding one of the following lines to your project’s
gradle.properties file:

Note: For a given build type, if you set useProguard to false in your app
module's build.gradle file, the Android Gradle plugin uses R8 to shrink your
app's code for that build type, regardless of whether you disable R8 in your
project's gradle.properties file.

ndkCompile is deprecated: You now get a build error if you try to use
ndkBuild to compile your native libraries. You should instead use either
CMake or ndk-build to
Add C and C++ code to your project.

Known issues

The correct usage of unique package names are currently not enforced but will
become more strict on later versions of the plugin. On Android Gradle plugin
version 3.4.0, you can opt-in to check whether your project declares
acceptable package names by adding the line below to your gradle.properties
file.

This minor update supports Android Studio 3.3.2 and includes various bug
fixes and performance improvements.
To see a list of noteable bug fixes, read the related post on the
Release Updates blog.

3.3.1 (February 2019)

This minor update supports Android Studio 3.3.1 and includes various bug
fixes and performance improvements.

New features

Improved classpath synchronization: When resolving dependencies on your
runtime and compile time classpaths, the Android Gradle plugin attempts to fix
certain downstream version conflicts for dependencies that appear across
multiple classpaths.

For example, if the runtime classpath includes Library A version 2.0 and the
compile classpath includes Library A version 1.0, the plugin automatically
updates the dependency on the compile classpath to Library A version 2.0 to
avoid errors.

However, if the runtime classpath includes Library A version 1.0 and the
compile includes Library A version 2.0, the plugin does not downgrade the
dependency on the compile classpath to Library A version 1.0, and you will get
an error. To learn more, see
Fix conflicts between classpaths.

Improved incremental Java compilation when using annotation processors:
This update decreases build time by improving support for incremental Java
compilation when using annotation processors.

Note: This feature is compatible with Gradle 4.10.1 and higher, except Gradle
5.1 due to Gradle issue 8194.

For projects using Kapt (most Kotlin-only projects and Kotlin-Java
hybrid projects): Incremental Java compilation is enabled, even when you
use data binding or the retro-lambda plugin. Annotation processing by the
Kapt task is not yet incremental.

For projects not using Kapt (Java-only projects): If the annotation
processors you use all support
incremental annotation processing,
incremental Java compilation is enabled by default. To monitor incremental
annotation processor adoption, watch
Gradle issue 5277.

If, however, one or more annotation processors do not support incremental
builds, incremental Java compilation is not enabled. Instead, you can
include the following flag in your gradle.properties file:

android.enableSeparateAnnotationProcessing=true

When you include this flag, the Android Gradle plugin executes the
annotation processors in a separate task and allows the Java compilation
task to run incrementally.

Better debug info when using obsolete API: When the plugin detects that
you're using an API that's no longer supported, it can now provide
more-detailed information to help you determine where that API is being used.
To see the additional info, you need to include the following in your
project's gradle.properties file:

android.debug.obsoleteApi=true

You can also enable the flag by passing -Pandroid.debug.obsoleteApi=true
from the command line.

You can run instrumentation tests on dynamic feature modules from the command
line.

Behavior changes

Lazy task configuration: The plugin now uses
Gradle’s new task creation API
to avoid initializing and configuring tasks that are not required to complete
the current build (or tasks not on the execution task graph). For example, if
you have multiple build variants, such as “release” and “debug” build
variants, and you're building the “debug” version of your app, the plugin
avoids initializing and configuring tasks for the “release” version of your
app.

Calling certain older methods in the Variants API, such as
variant.getJavaCompile(), might still force task configuration. To make sure
that your build is optimized for lazy task configuration, invoke new methods
that instead return a
TaskProvider
object, such as variant.getJavaCompileProvider().

For a given build type, when setting useProguard false, the plugin now
uses R8 instead of ProGuard to shrink and obfuscate your app’s code and
resources. To learn more about R8, read
this blog post
from the Android Developer’s Blog.

Faster R class generation for library projects: Previously, the Android
Gradle plugin would generate an R.java file for each of your project's
dependencies and then compile those R classes alongside your app's other
classes. The plugin now generates a JAR containing your app's compiled R class
directly, without first building intermediate R.java classes. This
optimization may significantly improve build performance for projects that
include many library subprojects and dependencies, and improve the indexing
speed in Android Studio.

When building an Android App Bundle, APKs generated from
that app bundle that target Android 6.0 (API level 23) or higher now include
uncompressed versions of your native libraries by default. This optimization
avoids the need for the device to make a copy of the library and thus reduces
the on-disk size of your app. If you'd rather disable this optimization, add
the following to your gradle.properties file:

android.bundle.enableUncompressedNativeLibs = false

The plugin enforces minimum versions of some third-party plugins.

Single-variant project sync:
Syncing your project
with your build configuration is an important step in letting Android Studio
understand how your project is structured. However, this process can be
time-consuming for large projects. If your project uses multiple build
variants, you can now optimize project syncs by limiting them to only the
variant you have currently selected.

You need to use Android Studio 3.3 or higher with Android Gradle Plugin 3.3.0
or higher to enable this optimization. When you meet these requirements, the
IDE prompts you to enable this optimization when you sync your project. The
optimization is also enabled by default on new projects.

Note: This optimization fully supports projects that
include Java and C++ languages, and has some support for Kotlin. When enabling
the optimization for projects with Kotlin content, Gradle sync falls back to
using full variants internally.

3.2.0 (September 2018)

With this update, you no longer need to specify a version for the SDK Build
Tools. The Android Gradle plugin now uses version 28.0.3 by default.

New features

Support for building Android App Bundles: The app bundle is a new upload
format that includes all your app’s compiled code and resources while
deferring APK generation and signing to the Google Play Store. You no longer
have to build, sign, and manage multiple APKs, and users get smaller downloads
that are optimized for their device. To learn more, read
About Android App Bundles.

Migration tool for AndroidX: When using Android Gradle plugin 3.2.0 with
Android 3.2 and higher, you can migrate your project’s local and Maven
dependencies to use the new AndroidX libraries by selecting Refactor >
Migrate to AndroidX from the menu bar. Using this migration tool also sets
the following flags to true in your gradle.properties file:

android.useAndroidX: When set to true, the Android plugin uses the
appropriate AndroidX library instead of a Support Library. When this flag
is not specified, the plugin sets it to false by default.

android.enableJetifier: When set to true, the Android plugin
automatically migrates existing third-party libraries to use AndroidX by
rewriting their binaries. When this flag is not specified, the plugin sets
it to false by default. You can set this flag to true only while
android.useAndroidX is also set to true, otherwise you get a build error.

New code shrinker, R8: R8 is a new tool for code shrinking and obfuscation
that replaces ProGuard. You can start using the preview version of R8 by
including the following in your project’s gradle.properties file:

android.enableR8 = true

Behavior changes

Desugaring with D8 is now enabled by default.

AAPT2 is now on Google's Maven repo. To use AAPT2, make sure that you have the
google() dependency in your build.gradle file, as shown below:

Native multidex is now enabled by default. Previous versions of Android
Studio enabled native multidex when deploying the debug version of an app to a
device running Android API level 21 or higher. Now, whether you’re deploying
to a device or building an APK for release, the Android Gradle plugin
enables native multidex for all modules that set minSdkVersion=21 or higher.

The plugin now enforces a minimum version of the protobuf plugin (0.8.6),
Kotlin plugin (1.2.50), and Crashlytics plugin (1.25.4).

The feature module plugin,com.android.feature, now enforces the use of only
letters, digits, and underscores when specifying a module name. For example,
if your feature module name includes dashes, you get a build error. This
behavior matches that of the dynamic feature module plugin.

Bug fixes

JavaCompile is now cacheable in projects with data binding.
(Issue #69243050)

3.1.0 (March 2018)

Build Tools 27.0.3 or higher.
Keep in mind, you no longer need to specify a version for the build
tools using the android.buildToolsVersion property—the plugin uses the
minimum required version by default.

New DEX compiler, D8

By default, Android Studio now uses a new DEX
compiler called D8. DEX compilation is the process of transforming .class
bytecode into .dex bytecode for the Android Runtime (or Dalvik, for older
versions of Android). Compared to the previous compiler, called DX, D8
compiles faster and outputs smaller DEX files, all while having the same or
better app runtime performance.

D8 shouldn't change your day-to-day app development workflow. However, if you
experience any issues related to the new compiler, please
report a bug. You can temporarily disable D8 and
use DX by including the following in your project's gradle.properties file:

android.enableD8=false

For projects that
use Java 8 language features,
incremental desugaring is enabled by default. You can disable it by
specifying the following in your project's gradle.properties file:

android.enableIncrementalDesugaring=false.

Preview users: If you're already using a preview version of D8, note
that it now compiles against libraries included in the
SDK build tools—not the JDK.
So, if you are accessing APIs that exist in the JDK but not in the SDK build
tools libraries, you get a compile error.

Behavior changes

When building multiple APKs that
each target a different ABI, the plugin no longer generates APKs for the
following ABIs by default: mips, mips64, and armeabi.

If you want to build APKs that target these ABIs, you must use
NDK r16b or lower and specify the ABIs
in your build.gradle file, as shown below:

splits {
abi {
include 'armeabi', 'mips', 'mips64'
...
}
}

When building configuration APKs
for an Android Instant App, language configuration
splits are now grouped by the root language by default. For example, if your
app includes resources for zh-TW or zh-CN locales, Gradle will package
those resources in a zh language configuration split. You can override this
behavior by defining your own groups using the include property, as shown
below:

The Android plugin's build cache now
evicts cache entries that are older than 30 days.

Passing "auto" to
resConfig
no longer automatically picks string resources to package into your APK. If
you continue to use "auto", the plugin packages all string resources your
app and its dependencies provide. So, you should instead specify each locale
that you want the plugin to package into your APK.

Because local modules can't depend on your app's test APK, adding
dependencies to your instrumented tests using the androidTestApi
configuration, instead of androidTestImplementation, causes Gradle to issue
the following warning:

WARNING: Configuration 'androidTestApi' is obsolete
and has been replaced with 'androidTestImplementation'

Fixes

Fixes an issue where you get a project sync error when loading the Android
plugin multiple times in a single build–for example, when multiple subprojects
each include the Android plugin in their buildscript classpath.

3.0.0 (October 2017)

Android Gradle plugin 3.0.0 includes a variety of changes that aim to
address performance issues of large projects.

For example, on a
sample skeleton project
with ~130 modules and a large number of external dependencies (but no
code or resources), you can experience performance improvements similar to the
following:

Android plugin version + Gradle version

Android plugin 2.2.0 + Gradle 2.14.1

Android plugin 2.3.0 + Gradle 3.3

Android plugin 3.0.0 + Gradle 4.1

Configuration (e.g. running ./gradlew --help)

~2 mins

~9 s

~2.5 s

1-line Java change (implementation change)

~2 mins 15 s

~29 s

~6.4 s

Some of these changes break existing builds. So, you should consider the effort
of migrating your project before using the new plugin.

If you don't experience the performance improvements described above, please
file a bug
and include a trace of your build using the
Gradle Profiler.

Build Tools 26.0.2 or higher.
With this update, you no longer need to specify a version for the build
tools—the plugin uses the minimum required version by default.
So, you can now remove the android.buildToolsVersion property.

3.0.1 (November 2017)

This is a minor update to support Android Studio 3.0.1, and includes general
bug fixes and performance improvements.

Optimizations

When making changes to dependency, Gradle performs faster builds by not
re-compiling modules that do not have access to that dependency's API.
You should restrict which dependencies leak their APIs to other modules by
using Gradle's new dependency configurations:
implementation, api, compileOnly, and runtimeOnly.

Faster incremental build speed due to per-class dexing. Each class is now
compiled into separate DEX files, and only the classes that are
modified are re-dexed. You should also expect improved build speeds for
apps that set minSdkVersion to 20 or lower, and use legacy multi-dex.

Improved build speeds by optimizing certain tasks to use chached outputs.
To benefit from this optimization, you need to first
enable the Gradle build cache.

Improved incremental resource processing using AAPT2, which is now enabled by
default.
If you are experiencing issues while using AAPT2, please
report a bug. You can also disable AAPT2 by
setting android.enableAapt2=false in your gradle.properties file and
restarting the Gradle daemon by running ./gradlew --stop from the command
line.

New features

Variant-aware dependency management.
When building a certain variant of
a module, the plugin now automatically matches variants of local library
module dependencies to the variant of the module you are building.

Built-in support for using certain Java 8 language features and Java 8
libraries.
Jack is now deprecated and no longer required, and you should first
disable Jack to use the improved Java 8 support built into the default
toolchain. For more information, read Use Java 8 language features.

Added support for running tests with
Android Test Orchestrator,
which allows you to run each of your app's tests within
its own invocation of Instrumentation. Because each test
runs in its own Instrumentation instance, any shared
state between tests doesn't accumulate on your device's CPU or memory. And,
even if one test crashes, it takes down only its own instance of
Instrumentation, so your other tests still run.

Added testOptions.execution to determine whether to use on-device test
orchestration. If you want to
use Android Test Orchestrator,
you need to specify ANDROID_TEST_ORCHESTRATOR, as shown below.
By default, this property is set to HOST, which disables on-device
orchestration and is the standard method of running tests.

android {
testOptions {
execution 'ANDROID_TEST_ORCHESTRATOR'
}
}

New androidTestUtil dependency configuration allows you to install
another test helper APK before running your instrumentation tests,
such as Android Test Orchestrator:

Added testOptions.unitTests.includeAndroidResources to support unit tests
that require Android resources, such as Roboelectric.
When you set this property to true, the plugin
performs resource, asset, and manifest merging before running your unit tests.
Your tests can then inspect com/android/tools/test_config.properties on the
classpath for the following keys:

android_merged_assets: the absolute path to the merged assets directory.

Note: For library modules, the merged assets do not contain the assets of dependencies
(see issue #65550419).

android_merged_manifest: the absolute path to the merged manifest file.

android_merged_resources: the absolute path to the merged resources
directory, which contains all the resources from the module and all its dependencies.

android_custom_package: the package name of the final R class. If
you dynamically modify the application ID, this package name may not
match the package attribute in the app's manifest.

New lintChecks dependency configuration allows you to build a JAR that
defines custom lint rules, and package it into your AAR and APK projects.
Your custom lint rules must belong to a separate project that outputs a single
JAR and includes only
compileOnly
dependencies. Other app and library modules can then depend on your lint project
using the lintChecks configuration:

dependencies {
// This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
// and package it with your module. If the module is an Android library,
// other projects that depend on it automatically use the lint checks.
// If the module is an app, lint includes these rules when analyzing the app.
lintChecks project(':lint-checks')
}

Behavior changes

Android plugin 3.0.0 removes certain APIs, and your build will break if you
use them. For example, you can no longer use the Variants API to access
outputFile() objects or use processManifest.manifestOutputFile() to get
the manifest file for each variant. To learn more, read
API changes.

You no longer need to specify a version for the build tools (so, you can now
remove the android.buildToolsVersion property). By default,
the plugin automatically uses the minimum required build tools version for the
version of Android plugin you're using.

You now enable/disable PNG crunching in the buildTypes block, as shown below.
PNG crunching is enabled by default for all builds except debug builds because
it increases build times for projects that include many
PNG files. So, to improve build times for other build types, you should either
disable PNG crunching or
convert your images to WebP.

Using the deprecated ndkCompile is now more restricted. You should instead
migrate to using either CMake or ndk-build to compile native code that you want
to package into your APK. To learn more, read
Migrate from ndkcompile.

Uses Gradle 3.3, which includes performance improvements and new features. For
more details, see the Gradle release notes.

Build cache: stores certain outputs that the Android plugin generates
when building your project (such as unpackaged AARs and pre-dexed remote
dependencies). Your clean builds are much faster while using the cache because
the build system can simply reuse those cached files during subsequent builds,
instead of recreating them. Projects using Android plugin 2.3.0 and higher use
the build cache by default. To learn more, read Improve Build Speed with Build Cache.

2.2.0 (September 2016)

Uses Gradle 2.14.1, which includes performance improvements
and new features, and fixes a security vulnerability that allows
local privilege escalation when using the Gradle daemon. For more
details, see the
Gradle release notes.

Using the externalNativeBuild {} DSL, Gradle now lets you
link to your native sources and compile native libraries using
CMake or ndk-build. After building your native libraries, Gradle
packages them into your APK. To learn more about using CMake and
ndk-build with Gradle, read Add C and C++ Code to Your
Project.

A new experimental caching feature lets Gradle speed up build
times by pre-dexing, storing, and reusing the pre-dexed versions of
your libraries. To learn more about using this experimental feature,
read the Build
Cache guide.

Improves build performance by adopting a new default packaging
pipeline which handles zipping, signing, and zipaligning in one task. You
can revert to using the older packaging tools by adding
android.useOldPackaging=true to your
gradle.properties file. While using the new packaging
tool, the zipalignDebug task is not available. However,
you can create one yourself by calling the
createZipAlignTask(String taskName, File inputFile, File
outputFile) method.

APK signing now uses APK Signature Scheme
v2 in addition to traditional JAR signing. All Android platforms accept the
resulting APKs. Any modification to these APKs after signing invalidates their
v2 signatures and prevents installation on a device. To disable this feature,
add the following to your module-level build.gradle file:

For multidex builds, you can now use ProGuard rules to determine which
classes Gradle should compile into your app’s main DEX file. Because
the Android system loads the main DEX file first when starting your app, you
can prioritize certain classes at startup by compiling them into the main DEX
file. After you create a ProGuard configuration file specifically for your
main DEX file, pass the configuration file’s path to Gradle using
buildTypes.multiDexKeepProguard. Using this DSL is different
from using buildTypes.proguardFiles, which provides general ProGuard
rules for your app and does not specify classes for the main DEX file.

Adds support for the android:extractNativeLibs flag,
which can reduce the size of your app when you install it on a
device. When you set this flag to false in the
<application>
element of your app manifest, Gradle packages uncompressed and
aligned versions of your native libraries with your APK. This
prevents PackageManager
from copying out your native libraries from the APK to the device's
file system during installation and has the added benefit of making
delta updates of your app smaller.

Improved support for annotation processors. Annotation
processors on your classpath, such as any compile
dependencies, are automatically applied to your build. You can
also specify an annotation processor in your build and pass
arguments by using the javaCompileOptions.annotationProcessorOptions {} DSL in your
module-level build.gradle file:

Note:Instant
Run does not currently work with Jack and will be disabled while
using the new toolchain. You only need to use Jack if you are developing
for the N Preview and want to use the supported Java 8 language features.

Added default support for incremental Java compilation to reduce
compilation time during development. It does this by only recompiling
portions of the source that have changed or need to be recompiled. To disable
this feature, add the following code to your module-level
build.gradle file:

android {
...
compileOptions {
incremental false
}
}

Added support for dexing-in-process which performs dexing within the build
process rather than in a separate, external VM processes. This not only makes
incremental builds faster, but also speeds up full builds. The feature is
enabled by default for projects that have set the Gradle daemon's maximum heap
size to at least 2048 MB. You can do this by including the following in your
project's gradle.properties file:

org.gradle.jvmargs = -Xmx2048m

If you have defined a value for javaMaxHeapSize in your module-level build.gradle
file, you need to set org.gradle.jvmargs to the value of
javaMaxHeapSize + 1024 MB. For example, if you have set
javaMaxHeapSize to "2048m", you need to add the following to your
project's gradle.properties file:

org.gradle.jvmargs = -Xmx3072m

To disable dexing-in-process, add the following code to your module-level build.gradle file:

2.0.0 (April 2016)

Enables Instant Run by
supporting bytecode injection, and pushing code and resource updates to a
running app on the emulator or a physical device.

Added support for incremental builds, even when the app isn’t running.
Full build times are improved by pushing incremental changes through the
Android Debug Bridge to the
connected device.

Added maxProcessCount to control how many slave dex processes can be
spawned concurrently. The following code, in the module-level
build.gradle file, sets the maximum number of concurrent processes
to 4:

Added an experimental code shrinker to support pre-dexing and reduce re-dexing
of dependencies, which are not supported with Proguard. This improves the build
speed of your debug build variant. Because the experimental shrinker does not
support optimization and obfuscation, you should enable Proguard for your
release builds. To enable the experimental shrinker for your debug builds, add
the following to your module-level build.gradle file:

Added logging support and improved performance for the resource shrinker.
The resource shrinker now logs all of its operations into a resources.txt
file located in the same folder as the Proguard log files.

Fixed an issue that caused duplicate AAR dependencies in both
the test and main build configurations.

Older releases

Android plugin for Gradle, revision 1.5.0 (November 2015)

Dependencies:

Gradle 2.2.1 or higher.

Build Tools 21.1.1 or higher.

General Notes:

Integrated the Data Binding plugin into the Android plugin for Gradle. To enable it, add
the following code to each per-project build.gradle file that uses the
plugin:

android {
dataBinding {
enabled = true
}
}

Added a new Transform API
to allow third-party plugins to manipulate compiled .class files before they’re
converted to .dex files. The Transform API simplifies injecting custom class
manipulations while offering more flexibility regarding what you can manipulate. To insert a
transform into a build, create a new class implementing one of the Transform
interfaces, and register it with android.registerTransform(theTransform) or
android.registerTransform(theTransform, dependencies). There’s no need to
wire tasks together. Note the following about the Transform API:

A transform can apply to one or more of the following: the current project, subprojects,
and external libraries.

A transform must be registered globally, which applies them to all variants.

Internal code processing, through the Java Code Coverage Library (JaCoCo), ProGuard,
and MultiDex, now uses the Transform API. However, the Java Android Compiler Kit
(Jack) doesn’t use this API: only the javac/dx code path does.

Gradle executes the transforms in this order: JaCoCo, third-party plugins, ProGuard.
The execution order for third-party plugins matches the order in which the transforms are
added by the third party plugins; third-party plugin developers can't control the execution
order of the transforms through an API.

Deprecated the dex getter from the ApplicationVariant class.
You can't access the Dex task through the variant API anymore because it’s now
accomplished through a transform. There's
currently no replacement for controlling the dex process.

Fixed incremental support for assets.

Improved MultiDex support by making it available for test projects, and
tests now automatically have the com.android.support:multidex-instrumentation
dependency.

Added the ability to properly fail a Gradle build and report the underlying error cause
when the Gradle build invokes asynchronous tasks and there’s a failure in the worker
process.

Added support for configuring a specific Application Binary Interface (ABI) in variants
that contain multiple ABIs.

Added support for a comma-separated list of device serial numbers for the
ANDROID_SERIAL environment variable when installing or running tests.

Fixed an installation failure on devices running Android 5.0 (API level 20) and higher
when the APK name contains a space.

Added JaCoCo incremental instrumentation support for faster incremental builds. The
Android plugin for Gradle now invokes the JaCoCo instrumenter directly. To force a newer
version of the JaCoCo instrumenter, you need to add it as a build script dependency.

Fixed JaCoCo support so it ignores files that aren’t classes.

Added vector drawable support for generating PNGs at build time for backward-compatibility.
Android plugin for Gradle generates PNGs for every vector drawable found in a resource
directory that doesn’t specify an API version or specifies an
android:minSdkVersion attribute of 20 or lower in the
<uses-sdk> element in the app manifest. You can set PNG densities by
using the generatedDensities property in the defaultConfig or
productFlavor sections of a build.gradle file.

Added sharing of the mockable android.jar, which the plugin generates only
once and uses for unit testing. Multiple modules, such as app and
lib, now share it. Delete $rootDir/build to regenerate it.

Changed the processing of Java resources to occur before the obfuscation tasks instead of
during the packaging of the APK. This change allows the obfuscation tasks to have a chance
to adapt the Java resources following packages obfuscation.

Fixed an issue with using Java Native Interface (JNI) code in the experimental library
plugin.

Added the ability to set the platform version separately from the
android:compileSdkVersion attribute in the experimental library
plugin.

Android plugin for Gradle, revision 1.3.1 (August 2015)

Dependencies:

Gradle 2.2.1 or higher.

Build Tools 21.1.1 or higher.

General Notes:

Fixed the ZipAlign task to properly
consume the output of the previous task when using a customized filename.

Added support for the com.android.build.threadPoolSize property to control
the Android task thread pool size from the gradle.properties file
or the command line. The following example sets this property to 4.

-Pcom.android.build.threadPoolSize=4

Set the default build behavior to exclude LICENSE and LICENSE.txt
files from APKs. To include these files in an APK, remove these files from the
packagingOptions.excludes property in the build.gradle file.
For example:

android {
packagingOptions.excludes = []
}

Added the sourceSets task to inspect the set of all available source sets.

Enhanced unit test support to recognize multi-flavor and
build variant source folders. For example, to test an app with multi-flavors
flavor1 and flavorA with the Debug build type,
the test source sets are:

test

testFlavor1

testFlavorA

testFlavor1FlavorA

testFlavor1FlavorADebug

Android tests already recognized multi-flavor source folders.

Improved unit test support to:

Run javac on main and test sources, even if the useJack
property is set to true in your build file.

Correctly recognize dependencies for each build type.

Added support for specifying instrumentation test-runner arguments from the command line.
For example:

Added support for a
test APK module as a separate test module, using the
targetProjectPath and targetVariant properties to set the APK
path and target variant.

Note: A test APK module does not support product
flavors and can only target a single variant. Also, Jacoco is not supported yet.

Added resource name validation before merging resources.

When building an AAR (Android ARchive) package for library modules, do not provide an
automatic @{applicationId} placeholder in the
manifest merger settings.
Instead, use a different placeholder, such as @{libApplicationId} and
provide a value for it if you want to include application Ids in the archive library.

Android plugin for Gradle, revision 1.2.0 (April 2015)

Dependencies:

Gradle 2.2.1 or higher.

Build Tools 21.1.1 or higher.

General Notes:

Enhanced support for running unit tests with Gradle.

Added support to include Java-style resources in the classpath when running unit
tests directly from Gradle.

Note: Test-only dependencies are not currently compatible
with Jack (Java Android Compiler Kit).

Added the android.testOptions.unitTests.returnDefaultValues option to
control the behaviour of the mockable android.jar.

Replaced Test in test task names with AndroidTest.
For example, the assembleDebugTest task is now
assembleDebugAndroidTest task. Unit test tasks still have UnitTest
in the task name, for example assembleDebugUnitTest.

Modified ProGuard configuration files to
no longer apply to the test APK. If minification is enabled, ProGuard processes the test APK
and applies only the mapping file that is generated when minifying the main APK.

Updated dependency management

Fixed issues using provided and package scopes.

Note: These scopes are incompatible with AAR
(Android ARchive) packages and will cause a build with AAR packages to fail.

Modified dependency resolution to compare the dependencies of an app under test and the
test app. If an artifact with the same version is found for both apps, it's not included with
the test app and is packaged only with the app under test. If an artifact with a different
version is found for both apps, the build fails.