BuildType

Application id suffix. It is appended to the "base" application id when calculating the final application id for a variant.

In case there are product flavor dimensions specified, the final application id suffix will contain the suffix from the default product flavor, followed by the suffix from product flavor of the first dimension, second dimension and so on. All of these will have a dot in between e.g. "defaultSuffix.dimension1Suffix.dimensions2Suffix".

ProGuard rule files to be included in the published AAR.

These proguard rule files will then be used by any application project that consumes the AAR (if ProGuard is enabled).

This allows AAR to specify shrinking or obfuscation exclude rules.

This is only valid for Library project. This is ignored in Application project.

Whether to crunch PNGs.

Setting this property to true reduces of PNG resources that are not already optimally compressed. However, this process increases build times.

PNG crunching is enabled by default in the release build type and disabled by default in the debug build type.

Whether this build type should generate a debuggable apk.

Whether a linked Android Wear app should be embedded in variant using this build type.

Wear apps can be linked with the following code:

dependencies {
  freeWearApp project(:wear:free') // applies to variant using the free flavor
  wearApp project(':wear:base') // applies to all other variants
}

Options for configuration Java compilation.

Whether this build type is configured to generate an APK with debuggable native code.

The manifest placeholders.

See Inject Build Variables into the Manifest.

Specifies a sorted list of build types that the plugin should try to use when a direct variant match with a local module dependency is not possible.

Android plugin 3.0.0 and higher try to match each variant of your module with the same one from its dependencies. For example, when you build a "freeDebug" version of your app, the plugin tries to match it with "freeDebug" versions of the local library modules the app depends on.

However, there may be situations in which your app includes build types that a dependency does not. For example, consider if your app includes a "stage" build type, but a dependency includes only a "debug" and "release" build type. When the plugin tries to build the "stage" version of your app, it won't know which version of the dependency to use, and you'll see an error message similar to the following:

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

In this situation, you can use matchingFallbacks to specify alternative matches for the app's "stage" build type, as shown below:

// In the app's build.gradle file.
android {
    buildTypes {
        release {
            // Because the dependency already includes a "release" build type,
            // you don't need to provide a list of fallbacks here.
        }
        stage {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "stage" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

Note that there is no issue when a library dependency includes a build type that your app does not. That's because the plugin simply never requests that build type from the dependency.

Whether removal of unused java code is enabled.

Default is false.

Whether Multi-Dex is enabled for this variant.

Text file that specifies additional classes that will be compiled into the main dex file.

Classes specified in the file are appended to the main dex classes computed using aapt.

If set, the file should contain one class per line, in the following format: com/example/MyClass.class

Text file with additional ProGuard rules to be used to determine which classes are compiled into the main dex file.

If set, rules from this file are used in combination with the default rules used by the build system.

Name of this build type.

Specifies the ProGuard configuration files that the plugin should use.

There are two ProGuard rules files that ship with the Android plugin and are used by default:

proguard-android-optimize.txt is identical to proguard-android.txt , exccept with optimizations enabled. You can use getDefaultProguardFile(String filename) to return the full path of the files.

Whether to generate pseudo locale in the APK.

If enabled, 2 fake pseudo locales (en-XA and ar-XB) will be added to the APK to help test internationalization support in the app.

Whether the build type is configured to generate an apk with debuggable RenderScript code.

Optimization level to use by the renderscript compiler.

Whether shrinking of unused resources is enabled. Default is false;

The signing configuration.

Whether test coverage is enabled for this build type.

If enabled this uses Jacoco to capture coverage and creates a report in the build directory.

The version of Jacoco can be configured with:

android {
  jacoco {
    version = '0.6.2.201302030002'
  }
}

The Jack toolchain is deprecated.

If you want to use Java 8 language features, use the improved support included in the default toolchain. To learn more, read Use Java 8 language features.

Specifies whether to always use ProGuard for code and resource shrinking.

By default, when you enable code shrinking by setting minifyEnabled to true, the Android plugin uses ProGuard. However while deploying your app using Android Studio's Instant Run feature, which doesn't support ProGuard, the plugin switches to using a custom experimental code shrinker.

If you experience issues using the experimental code shrinker, you can disable code shrinking while using Instant Run by setting this property to true.

To learn more, read Shrink Your Code and Resources.

Version name suffix. It is appended to the "base" version name when calculating the final version name for a variant.

In case there are product flavor dimensions specified, the final version name suffix will contain the suffix from the default product flavor, followed by the suffix from product flavor of the first dimension, second dimension and so on.

Whether zipalign is enabled for this build type.

Adds a new field to the generated BuildConfig class.

The field is generated as: <type> <name> = <value>;

This means each of these must have valid Java content. If the type is a String, then the value should include quotes.

Adds a proguard rule file to be included in the published AAR.

This proguard rule file will then be used by any application project that consume the AAR (if proguard is enabled).

This allows AAR to specify shrinking or obfuscation exclude rules.

This is only valid for Library project. This is ignored in Application project.

Adds proguard rule files to be included in the published AAR.

This proguard rule file will then be used by any application project that consume the AAR (if proguard is enabled).

This allows AAR to specify shrinking or obfuscation exclude rules.

This is only valid for Library project. This is ignored in Application project.

Configure native build options.

Copies all properties from the given build type.

It can be used like this:

android.buildTypes {
    customBuildType {
        initWith debug
            // customize...
        }
}

Adds a new ProGuard configuration file.

proguardFile getDefaultProguardFile('proguard-android.txt')

There are 2 default rules files

They are located in the SDK. Using getDefaultProguardFile(String filename) will return the full path to the files. They are identical except for enabling optimizations.

Adds new ProGuard configuration files.

There are 2 default rules files

They are located in the SDK. Using getDefaultProguardFile(String filename) will return the full path to the files. They are identical except for enabling optimizations.

Adds a new generated resource.

This is equivalent to specifying a resource in res/values.

See Resource Types.

Adds a new generated resource.

This is equivalent to specifying a resource in res/values.

See Resource Types.

Sets the ProGuard configuration files.

There are 2 default rules files

They are located in the SDK. Using getDefaultProguardFile(String filename) will return the full path to the files. They are identical except for enabling optimizations.