LibraryBuildType

Options for configuring AAR metadata.

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.

Returns whether multi-dex is enabled.

This can be null if the flag is not set, in which case the default value is used.

The associated signing config or null if none are set on the variant dimension.

Encapsulates per-variant CMake and ndk-build configurations for your external native build.

To learn more, see Add C and C++ Code to Your Project.

Encapsulates per-variant CMake and ndk-build configurations for your external native build.

To learn more, see Add C and C++ Code to Your Project.

Options for configuring Java compilation.

Options for configuring Java compilation.

The manifest placeholders.

See Inject Build Variables into the Manifest.

The manifest placeholders.

See Inject Build Variables into the Manifest.

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

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.

Encapsulates per-variant configurations for the NDK, such as ABI filters.

Encapsulates per-variant configurations for the NDK, such as ABI filters.

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.txt
• proguard-android-optimize.txt

proguard-android-optimize.txt is identical to proguard-android.txt, except with optimizations enabled. You can use getDefaultProguardFileString to return the full path of the files.

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.txt
• proguard-android-optimize.txt

proguard-android-optimize.txt is identical to proguard-android.txt, except with optimizations enabled. You can use getDefaultProguardFileString to return the full path of the files.

Options for configuring the shader compiler.

Options for configuring the shader compiler.

The collection of proguard rule files to be used when processing test code.

Test code needs to be processed to apply the same obfuscation as was done to main code.

The collection of proguard rule files to be used when processing test code.

Test code needs to be processed to apply the same obfuscation as was done to main code.

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

Specifies whether to enable code shrinking for this build type.

By default, when you enable code shrinking by setting this property to true, the Android plugin uses ProGuard.

To learn more, read Shrink Your Code and Resources.

Specifies whether the plugin should generate resources for pseudolocales.

A pseudolocale is a locale that simulates characteristics of languages that cause UI, layout, and other translation-related problems when an app is localized. Pseudolocales can aid your development workflow because you can test and make adjustments to your UI before you finalize text for translation.

When you set this property to true as shown below, the plugin generates resources for the following pseudo locales and makes them available in your connected device's language preferences: en-XA and ar-XB.

android {
    buildTypes {
        debug {
            pseudoLocalesEnabled true
        }
    }
}

When you build your app, the plugin includes the pseudolocale resources in your APK. If you notice that your APK does not include those locale resources, make sure your build configuration isn't limiting which locale resources are packaged with your APK, such as using the resourceConfigurations property to remove unused locale resources.

To learn more, read Test Your App with Pseudolocales.

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

Specifies whether to enable shrinking resources for this build type.

To learn more, read Shrink Your Code and Resources.

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 {
    testCoverage {
        jacocoVersion = '0.6.2.201302030002'
    }
}

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

Optimization level to use by the renderscript compiler.