public interface AndroidConfig
Modifier and Type | Method and Description |
---|---|
com.android.build.gradle.internal.dsl.AaptOptions |
getAaptOptions()
Specifies options for the Android Asset Packaging Tool (AAPT).
|
com.android.build.gradle.internal.dsl.AdbOptions |
getAdbOptions()
Specifies APK install options for the Android Debug Bridge
(ADB).
|
java.util.Collection<java.lang.String> |
getAidlPackageWhiteList()
Aidl files to package in the aar.
|
java.lang.Boolean |
getBaseFeature()
Whether the feature module is the base feature.
|
java.util.List<java.io.File> |
getBootClasspath()
Returns the list of files that form bootClasspath used for compilation.
|
java.util.Collection<BaseVariantOutput> |
getBuildOutputs()
build outputs for all variants
|
com.android.repository.Revision |
getBuildToolsRevision()
This property is for internal use only.
|
java.lang.String |
getBuildToolsVersion()
Specifies the version of the SDK Build Tools to
use when building your project.
|
java.util.Collection<? extends com.android.build.gradle.internal.dsl.CoreBuildType> |
getBuildTypes()
Encapsulates all build type configurations for this project.
|
com.android.build.gradle.internal.CompileOptions |
getCompileOptions()
Specifies Java compiler options, such as the language level of the Java source code and
generated bytecode.
|
java.lang.String |
getCompileSdkVersion()
Specifies the API level to compile your project against.
|
com.android.builder.model.DataBindingOptions |
getDataBinding()
Specifies options for the Data Binding
Library.
|
com.android.build.gradle.internal.dsl.CoreProductFlavor |
getDefaultConfig()
Specifies defaults for variant properties that the Android plugin applies to all build
variants.
|
java.lang.String |
getDefaultPublishConfig()
Specifies the version of the module to publish externally.
|
java.util.List<com.android.builder.testing.api.DeviceProvider> |
getDeviceProviders()
List of device providers
|
com.android.build.gradle.internal.dsl.DexOptions |
getDexOptions()
Specifies options for the DEX tool, such as enabling library pre-dexing.
|
com.android.build.gradle.internal.model.CoreExternalNativeBuild |
getExternalNativeBuild()
|
java.util.List<java.lang.String> |
getFlavorDimensionList()
Specifies the names of product flavor dimensions for this project.
|
boolean |
getGeneratePureSplits()
Specifies whether to build APK splits or multiple APKs from configurations in the
splits block. |
com.android.build.gradle.internal.coverage.JacocoOptions |
getJacoco()
Configure JaCoCo version that is used for offline instrumentation and coverage report.
|
java.util.Collection<com.android.builder.core.LibraryRequest> |
getLibraryRequests() |
com.android.build.gradle.internal.dsl.LintOptions |
getLintOptions()
Specifies options for the lint tool.
|
java.lang.String |
getNdkVersion()
Name of the NDK version that will be used when building native code.
|
java.lang.Boolean |
getPackageBuildConfig()
Whether to package build config class file.
|
com.android.build.gradle.internal.dsl.PackagingOptions |
getPackagingOptions()
Specifies options and rules that determine which files the Android plugin packages into your
APK.
|
java.util.Collection<? extends com.android.build.gradle.internal.dsl.CoreProductFlavor> |
getProductFlavors()
Encapsulates all product flavors configurations for this project.
|
java.lang.String |
getResourcePrefix()
Specifies the module's resource prefix to Android Studio for editor features, such as Lint
checks.
|
java.util.Collection<? extends com.android.builder.model.SigningConfig> |
getSigningConfigs()
Encapsulates signing configurations that you can apply to
BuildType and ProductFlavor configurations. |
org.gradle.api.NamedDomainObjectContainer<AndroidSourceSet> |
getSourceSets()
Encapsulates source set configurations for all variants.
|
com.android.build.gradle.internal.dsl.Splits |
getSplits()
Specifies configurations for building multiple
APKs or APK splits.
|
java.lang.String |
getTestBuildType()
Name of the build type that will be used when running Android (on-device) tests.
|
com.android.build.gradle.internal.dsl.TestOptions |
getTestOptions()
Specifies options for how the Android plugin should run local and instrumented tests.
|
java.util.List<com.android.builder.testing.api.TestServer> |
getTestServers()
List of remote CI servers.
|
java.util.List<com.android.build.api.transform.Transform> |
getTransforms() |
java.util.List<java.util.List<java.lang.Object>> |
getTransformsDependencies() |
org.gradle.api.Action<com.android.build.api.variant.VariantFilter> |
getVariantFilter()
Specifies variants the Android plugin should include or remove from your Gradle project.
|
java.lang.String getBuildToolsVersion()
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:
// 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.
java.lang.String getCompileSdkVersion()
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: compileSdkVersion 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.
@Internal com.android.repository.Revision getBuildToolsRevision()
To specify the version of the SDK Build Tools that the Android plugin should use, use buildToolsVersion instead.
java.lang.String getDefaultPublishConfig()
If you don't configure this property, the Android plugin publishes the release version of the module by default. If the module configures product flavors, you need to configure this property with the name of the variant you want the plugin to publish, as shown below:
// Specifies the 'demoDebug' build variant as the default variant // that the plugin should publish to external consumers. defaultPublishConfig 'demoDebug'
If you plan to only consume your library module locally, you do not need to configure this property. Android plugin 3.0.0 and higher use variant-aware dependency resolution to automatically match the variant of the producer to that of the consumer. That is, when publishing a module to another local module, the plugin no longer respects this property when determining which version of the module to publish to the consumer.
org.gradle.api.Action<com.android.build.api.variant.VariantFilter> getVariantFilter()
By default, the Android plugin creates a build variant for every possible combination of
the product flavors and build types that you configure, and adds them to your Gradle project.
However, there may be certain build variants that either you do not need or do not make sense
in the context of your project. You can remove certain build variant configurations by creating
a variant filter in your module-level build.gradle
file.
The following example tells the plugin to ignore all variants that combine the "dev" product flavor, which you can configure to optimize build speeds during development, and the "release" build type:
android { ... variantFilter { variant -> def buildTypeName = variant.buildType*.name def flavorName = variant.flavors*.name if (flavorName.contains("dev") && buildTypeName.contains("release")) { // Tells Gradle to ignore each variant that satisfies the conditions above. setIgnore(true) } } }
During subsequent builds, Gradle ignores any build variants that meet the conditions you specify. If you're using Android Studio, those variants no longer appear in the drop down menu when you click Build > Select Build Variant from the menu bar.
VariantFilter
com.android.build.gradle.internal.dsl.AdbOptions getAdbOptions()
AdbOptions
java.lang.String getResourcePrefix()
Including unique prefixes for module resources helps avoid naming collisions with
resources from other modules. 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 module
resources:
// This property is useful only when developing your project in Android Studio. resourcePrefix 'mylib_'
java.util.List<java.lang.String> getFlavorDimensionList()
To configure flavor dimensions, use
flavorDimensions
. To learn more, read combine
multiple product flavors.
@Incubating boolean getGeneratePureSplits()
splits
block.
When you set this property to true
, the Android plugin generates each object
in the splits
block as a portion of a
whole APK, called an APK split. Compared to building multiple APKs, each APK split
includes only the components that each ABI or screen density requires. Generating APK splits
is an incubating feature, which requires you to set BaseFlavor.minSdkVersion(int)
to 21
or
higher, and is currently supported only when publishing Android Instant Apps.
When you do not configure this property or set it to false
(default), the
Android plugin builds separate APKs for each object you configure in the splits
block that you can deploy to a device.
To learn more about building different versions of your app that each target a different Application Binary Interfaces
or screen density, read Build Multiple
APKs.
com.android.build.gradle.internal.dsl.CoreProductFlavor getDefaultConfig()
You can override any defaultConfig
property when configuring
product flavors.
ProductFlavor
com.android.build.gradle.internal.dsl.AaptOptions getAaptOptions()
AaptOptions
com.android.build.gradle.internal.CompileOptions getCompileOptions()
CompileOptions
com.android.build.gradle.internal.dsl.DexOptions getDexOptions()
Experimenting with DEX options tailored for your workstation may improve build performance. To learn more, read Optimize your build.
DexOptions
com.android.build.gradle.internal.coverage.JacocoOptions getJacoco()
To specify the version of JaCoCo you want to use, add the following to build.gradle
file:
android { jacoco { version "<jacoco-version>" } }
com.android.build.gradle.internal.dsl.LintOptions getLintOptions()
Android Studio and the Android SDK provide a code scanning tool called lint that can help you to identify and correct problems with the structural quality of your code without having to execute the app or write test cases. Each problem the tool detects is reported with a description message and a severity level, so that you can quickly prioritize the critical improvements that need to be made.
This property allows you to configure certain lint options, such as which checks to run or ignore. If you're using Android Studio, you can configure similar lint options from the IDE. To learn more about using and running lint, read Improve Your Code with Lint.
LintOptions
com.android.build.gradle.internal.model.CoreExternalNativeBuild getExternalNativeBuild()
When using Android Studio 2.2 or higher with Android plugin 2.2.0 or higher, you can compile C and C++ code into a native library that Gradle packages into your APK.
To learn more, read Add C and C++ Code to Your Project.
ExternalNativeBuild
com.android.build.gradle.internal.dsl.PackagingOptions getPackagingOptions()
For example, the following example tells the plugin to avoid packaging files that are intended only for testing:
packagingOptions { // Tells the plugin to not include any files in the 'testing-data/' directory, // which is specified as an absolute path from the root of the APK archive. // The exclude property includes certain defaults paths to help you avoid common // duplicate file errors when building projects with multiple dependencies. exclude "/testing-data/**" }
To learn more about how to specify rules for packaging, merging, and excluding files, see
PackagingOptions
PackagingOptions
com.android.build.gradle.internal.dsl.Splits getSplits()
To generate APK splits, you need to also set
generatePureSplits
to true
. However, generating APK splits is
an incubating feature, which requires you to set BaseFlavor.minSdkVersion(int)
to 21
or
higher, and is currently supported only when publishing Android Instant Apps.
Splits
com.android.build.gradle.internal.dsl.TestOptions getTestOptions()
To learn more, read Configure Gradle test options.
TestOptions
@NonNull java.util.List<com.android.builder.testing.api.DeviceProvider> getDeviceProviders()
@NonNull java.util.List<com.android.builder.testing.api.TestServer> getTestServers()
@NonNull java.util.List<com.android.build.api.transform.Transform> getTransforms()
@NonNull java.util.List<java.util.List<java.lang.Object>> getTransformsDependencies()
java.util.Collection<? extends com.android.build.gradle.internal.dsl.CoreProductFlavor> getProductFlavors()
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 module'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 a ProductFlavor
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 a
flavorDimensions
value. 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.
ProductFlavor
java.util.Collection<? extends com.android.build.gradle.internal.dsl.CoreBuildType> getBuildTypes()
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.
BuildType
java.util.Collection<? extends com.android.builder.model.SigningConfig> getSigningConfigs()
BuildType
and ProductFlavor
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.
SigningConfig
org.gradle.api.NamedDomainObjectContainer<AndroidSourceSet> getSourceSets()
The Android plugin looks for your project's source code and resources in groups of
directories called source sets.
Each source set also determines the scope of build outputs that should consume its code and
resources. For example, when creating a new project from Android Studio, the IDE creates
directories for a main/
source set that contains the code and resources you want
to share between all your build variants.
You can then define basic functionality in the main/
source set, but use
product flavor source sets to change only the branding of your app between different clients,
or include special permissions and logging functionality to only "debug" versions of your
app.
The Android plugin expects you to organize files for source set directories a certain way,
similar to the main/
source set. For example, Gradle expects Java class files
that are specific to your "debug" build type to be located in the src/debug/java/
directory.
Gradle provides a useful task to shows you how to organize your files for each build type-, product flavor-, and build variant-specific source set. you can run this task from the command line as follows:
./gradlew sourceSets
The following sample output describes where Gradle expects to find certain files for the "debug" build type:
------------------------------------------------------------ Project :app ------------------------------------------------------------ ... debug ---- Compile configuration: compile build.gradle name: android.sourceSets.debug Java sources: [app/src/debug/java] Manifest file: app/src/debug/AndroidManifest.xml Android resources: [app/src/debug/res] Assets: [app/src/debug/assets] AIDL sources: [app/src/debug/aidl] RenderScript sources: [app/src/debug/rs] JNI sources: [app/src/debug/jni] JNI libraries: [app/src/debug/jniLibs] Java-style resources: [app/src/debug/resources]
If you have sources that are not organized into the default source set directories that
Gradle expects, as described in the sample output above, you can use the sourceSet
block to change where Gradle looks to gather files for each component of a given
source set. You don't need to relocate the files; you only need to provide Gradle with the
path(s), relative to the module-level build.gradle
file, where Gradle should
expect to find files for each source set component.
Note: You should specify only static paths whenever possible. Specifying dynamic paths reduces build speed and consistency.
The following code sample maps sources from the app/other/
directory to
certain components of the main
source set and changes the root directory of the
androidTest
source set:
android { ... sourceSets { // Encapsulates configurations for the main source set. main { // Changes the directory for Java sources. The default directory is // 'src/main/java'. java.srcDirs = ['other/java'] // If you list multiple directories, Gradle uses all of them to collect // sources. Because Gradle gives these directories equal priority, if // you define the same resource in more than one directory, you get an // error when merging resources. The default directory is 'src/main/res'. res.srcDirs = ['other/res1', 'other/res2'] // Note: You should avoid specifying a directory which is a parent to one // or more other directories you specify. For example, avoid the following: // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings'] // You should specify either only the root 'other/res1' directory, or only the // nested 'other/res1/layouts' and 'other/res1/strings' directories. // For each source set, you can specify only one Android manifest. // By default, Android Studio creates a manifest for your main source // set in the src/main/ directory. manifest.srcFile 'other/AndroidManifest.xml' ... } // Create additional blocks to configure other source sets. androidTest { // If all the files for a source set are located under a single root // directory, you can specify that directory using the setRoot property. // When gathering sources for the source set, Gradle looks only in locations // relative to the root directory you specify. For example, after applying the // configuration below for the androidTest source set, Gradle looks for Java // sources only in the src/tests/java/ directory. setRoot 'src/tests' ... } } }
AndroidSourceSetFactory
java.util.Collection<BaseVariantOutput> getBuildOutputs()
java.lang.Boolean getPackageBuildConfig()
java.util.Collection<java.lang.String> getAidlPackageWhiteList()
java.util.Collection<com.android.builder.core.LibraryRequest> getLibraryRequests()
com.android.builder.model.DataBindingOptions getDataBinding()
Data binding helps you write declarative layouts and minimize the glue code necessary to bind your application logic and layouts.
java.lang.Boolean getBaseFeature()
@Nullable java.lang.String getTestBuildType()
Defaults to "debug".
FIXME this should not be here, but it has to be because of gradle-core not knowing anything besides this interface. This will be fixed with the new gradle-api based extension interfaces.
@Nullable java.lang.String getNdkVersion()
The value null means that no particular NDK version is requested. In this case, the latest available NDK will be used.
java.util.List<java.io.File> getBootClasspath()