DynamicFeatureExtension

Specifies options for the Android Asset Packaging Tool (AAPT).

For more information about the properties you can configure in this block, see AaptOptions.

Specifies options for the Android Debug Bridge (ADB), such as APK installation options.

For more information about the properties you can configure in this block, see AdbOptions.

A list of build features that can be enabled or disabled on the Android Project.

Specifies the version of the SDK Build Tools to use when building your project.

When using Android plugin 3.0.0 or later, configuring this property is optional. By default, the plugin uses the minimum version of the build tools required by the version of the plugin you're using. To specify a different version of the build tools for the plugin to use, specify the version as follows:

android {
    // Specifying this property is optional.
    buildToolsVersion "26.0.0"
}

For a list of build tools releases, read the release notes.

Note that the value assigned to this property is parsed and stored in a normalized form, so reading it back may give a slightly different result.

Encapsulates all build type configurations for this project.

Unlike using ProductFlavor to create different versions of your project that you expect to co-exist on a single device, build types determine how Gradle builds and packages each version of your project. Developers typically use them to configure projects for various stages of a development lifecycle. For example, when creating a new project from Android Studio, the Android plugin configures a 'debug' and 'release' build type for you. By default, the 'debug' build type enables debugging options and signs your APK with a generic debug keystore. Conversely, The 'release' build type strips out debug symbols and requires you to create a release key and keystore for your app. You can then combine build types with product flavors to create build variants.

Specifies Java compiler options, such as the language level of the Java source code and generated bytecode.

For more information about the properties you can configure in this block, see CompileOptions.

Specifies the API level to compile your project against. The Android plugin requires you to configure this property.

This means your code can use only the Android APIs included in that API level and lower. You can configure the compile sdk version by adding the following to the android block: compileSdk 26.

You should generally use the most up-to-date API level available. If you are planning to also support older API levels, it's good practice to use the Lint tool to check if you are using APIs that are not available in earlier API levels.

The value you assign to this property is parsed and stored in a normalized form, so reading it back may return a slightly different value.

Specifies options for the Data Binding Library.

For more information about the properties you can configure in this block, see DataBinding

Specifies defaults for variant properties that the Android plugin applies to all build variants.

You can override any defaultConfig property when configuring product flavors

For more information about the properties you can configure in this block, see DefaultConfig.

Specifies the names of product flavor dimensions for this project.

When configuring product flavors with Android plugin 3.0.0 and higher, you must specify at least one flavor dimension, using the flavorDimensions property, and then assign each flavor to a dimension. Otherwise, you will get the following build error:

Error:All flavors must now belong to a named flavor dimension.
The flavor 'flavor_name' is not assigned to a flavor dimension.

By default, when you specify only one dimension, all flavors you configure automatically belong to that dimension. If you specify more than one dimension, you need to manually assign each flavor to a dimension, as shown in the sample below.

Flavor dimensions allow you to create groups of product flavors that you can combine with flavors from other flavor dimensions. For example, you can have one dimension that includes a 'free' and 'paid' version of your app, and another dimension for flavors that support different API levels, such as 'minApi21' and 'minApi24'. The Android plugin can then combine flavors from these dimensions—including their settings, code, and resources—to create variants such as 'debugFreeMinApi21' and 'releasePaidMinApi24', and so on. The sample below shows you how to specify flavor dimensions and add product flavors to them.

android {
    ...
    // Specifies the flavor dimensions you want to use. The order in which you
    // list each dimension determines its priority, from highest to lowest,
    // when Gradle merges variant sources and configurations. You must assign
    // each product flavor you configure to one of the flavor dimensions.
    flavorDimensions 'api', 'version'

    productFlavors {
      demo {
        // Assigns this product flavor to the 'version' flavor dimension.
        dimension 'version'
        ...
    }

      full {
        dimension 'version'
        ...
      }

      minApi24 {
        // Assigns this flavor to the 'api' dimension.
        dimension 'api'
        minSdkVersion '24'
        versionNameSuffix "-minApi24"
        ...
      }

      minApi21 {
        dimension "api"
        minSdkVersion '21'
        versionNameSuffix "-minApi21"
        ...
      }
   }
}

To learn more, read Combine multiple flavors.

Configure JaCoCo version that is used for offline instrumentation and coverage report.

To specify the version of JaCoCo you want to use, add the following to build.gradle file:

android {
    jacoco {
        version "<jacoco-version>"
    }
}

Specifies options for the lint tool.

For more information about the properties you can configure in this block, see LintOptions.

Requires the specified path to NDK be used.

Use this to specify a path to the NDK folder to be used for C and C++ builds.

android {
    // Path to custom NDK location
    ndkPath '/path/to/ndk'
}

If this field is specified then android.ndkVersion may not be specified.

For additional information about NDK installation see Install and configure the NDK.

Requires the specified NDK version to be used.

Use this to specify a fixed NDK version. Without this, each new version of the Android Gradle Plugin will choose a specific version of NDK to use, so upgrading the plugin also means upgrading the NDK. Locking to a specific version can increase repeatability of the build.

android {
    // Use a fixed NDK version
    ndkVersion '20.1.5948944'
}

If this field is specified then android.ndkPath may not be specified.

The required format of the version is major.minor.build. It's not legal to specify less precision. If ndk.dir is specified in local.properties file then the NDK that it points to must match the android.ndkVersion.

Prior to Android Gradle Plugin version 3.5, the highest installed version of NDK will be used. In Android Gradle Plugin 3.4, specifying android.ndkVersion was not an error, but the value would be ignored. Prior to Android Gradle Plugin version 3.4, it was illegal to specify android.ndkVersion.

For additional information about NDK installation see Install and configure the NDK.

A registrar to apply actions on subsets of VariantPropertiesT via filters.

A registrar to apply actions on subsets of VariantT via filters.

Specifies options and rules that determine which files the Android plugin packages into your APK.

For more information about the properties you can configure in this block, see PackagingOptions.

Encapsulates all product flavors configurations for this project.

Product flavors represent different versions of your project that you expect to co-exist on a single device, the Google Play store, or repository. For example, you can configure 'demo' and 'full' product flavors for your app, and each of those flavors can specify different features, device requirements, resources, and application ID's--while sharing common source code and resources. So, product flavors allow you to output different versions of your project by simply changing only the components and settings that are different between them.

Configuring product flavors is similar to configuring build types: add them to the productFlavors block of your project's build.gradle file and configure the settings you want. Product flavors support the same properties as the defaultConfig block--this is because defaultConfig defines an object that the plugin uses as the base configuration for all other flavors. Each flavor you configure can then override any of the default values in defaultConfig, such as the applicationId.

When using Android plugin 3.0.0 and higher, each flavor must belong to aflavorDimensionvalue. By default, when you specify only one dimension, all flavors you configure belong to that dimension. If you specify more than one flavor dimension, you need to manually assign each flavor to a dimension. To learn more, read Use Flavor Dimensions for variant-aware dependency management.

When you configure product flavors, the Android plugin automatically combines them with your BuildType configurations to create build variants. If the plugin creates certain build variants that you don't want, you can filter variants.

Specifies this project's resource prefix to Android Studio for editor features, such as Lint checks. This property is useful only when using Android Studio.

Including unique prefixes for project resources helps avoid naming collisions with resources from other projects.

For example, when creating a library with String resources, you may want to name each resource with a unique prefix, such as "mylib_" to avoid naming collisions with similar resources that the consumer defines.

You can then specify this prefix, as shown below, so that Android Studio expects this prefix when you name project resources:

// This property is useful only when developing your project in Android Studio.
resourcePrefix 'mylib_'

Encapsulates signing configurations that you can apply to [ ] and [ ] configurations.

Android requires that all APKs be digitally signed with a certificate before they can be installed onto a device. When deploying a debug version of your project from Android Studio, the Android plugin automatically signs your APK with a generic debug certificate. However, to build an APK for release, you must sign the APK with a release key and keystore. You can do this by either using the Android Studio UI or manually configuring your build.gradle file.

Encapsulates source set configurations for all variants.

Note that the Android plugin uses its own implementation of source sets. For more information about the properties you can configure in this block, see AndroidSourceSet.

Specifies configurations for building multiple APKs or APK splits.

For more information about the properties you can configure in this block, see Splits.

Specifies options for how the Android plugin should run local and instrumented tests.

For more information about the properties you can configure in this block, see TestOptions.

Specifies the build type that the plugin should use to test the module.

By default, the Android plugin uses the "debug" build type. This means that when you deploy your instrumented tests using gradlew connectedAndroidTest, it uses the code and resources from the module's "debug" build type to create the test APK. The plugin then deploys the "debug" version of both the module's APK and the test APK to a connected device, and runs your tests.

To change the test build type to something other than "debug", specify it as follows:

android {
    // Changes the test build type for instrumented tests to "stage".
    testBuildType "stage"
}

If your module configures product flavors the plugin creates a test APK and deploys tests for each build variant that uses the test build type. For example, consider if your module configures "debug" and "release" build types, and "free" and "paid" product flavors. By default, when you run your instrumented tests using gradlew connectedAndroidTest, the plugin performs executes the following tasks:

• connectedFreeDebugAndroidTest: builds and deploys a freeDebug test APK and module APK, and runs instrumented tests for that variant.
• connectedPaidDebugAndroidTest: builds and deploys a paidDebug test APK and module APK, and runs instrumented tests for that variant.

To learn more, read Create instrumented test for a build variant

Note: You can execute connected<BuildVariant>AndroidTest tasks only for build variants that use the test build type. So, by default, running connectedStageAndroidTest results in the following build error:

Task 'connectedStageAndroidTest' not found in root project

You can resolve this issue by changing the test build type to "stage".