Android-gradle-simple introduction 4: Configuring manifest in the Custom Build Process
The Android Gradle plug-in provides a large number of DSL custom build processes. This blog explains how to configure manifest in gradle.
DSL provides the ability to configure the following Manifest entries:
MinSdkVersion
TargetSdkVersion
VersionCode
VersionName
ApplicationId (more convenient and effective package name -- [Reference] (http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename ))
Package name of the test app
Instrumentation test runner
Example:
android { compileSdkVersion 19 buildToolsVersion 19.0.0 defaultConfig { versionCode 12 versionName 2.0 minSdkVersion 16 targetSdkVersion 16 }}
The defaultConfig element in the android element is where we configure Manifest. In earlier versions, the Android plug-in uses packageName to configure the packageName attribute in manifest. From 0.11.0, applicationId is used to replace packageName. This eliminates the confusion between the application package name (actually the Application id) and java package name.
What's more powerful is that the configurations described in the build file can be dynamic. For example, you can get the version name from the file or custom logic.
def computeVersionName() { ...}android { compileSdkVersion 19 buildToolsVersion 19.0.0 defaultConfig { versionCode 12 versionName computeVersionName() minSdkVersion 16 targetSdkVersion 16 }}
Note: Do not use the getter method name in the scope as the function name. For example, if getVersionName () is called in the defaultConfig {} scope, defaconfig config will be automatically called. getVersionName (), instead of calling a custom method.
If the value of an attribute is not set using DSL, some default values are used for this attribute. The following table shows the processing process of the default values.
Property name default value in DSL object
Property Name |
Default value in DSL object |
Default value |
VersionCode |
-1 |
Value from manifest if present |
VersionName |
Null |
Value from manifest if present |
MinSdkVersion |
-1 |
Value from manifest if present |
TargetSdkVersion |
-1 |
Value from manifest if present |
ApplicationId |
Null |
Value from manifest if present |
TestApplicationId |
Null |
ApplicationId + ". test" |
TestInstrumentationRunner |
Null |
Android. test. InstrumentationTestRunner |
SigningConfig |
Null |
Null |
ProguardFile |
N/A (set only) |
N/A (set only) |
ProguardFiles |
N/A (set only) |
N/A (set only) |
If you want to use custom logic in the build script to query these attributes, the value in the second column is very important. For example, you can write the following code:
if (android.defaultConfig.testInstrumentationRunner == null) { // assign a better default...}
If the attribute value is still null, the default values of the third column will be used during construction, but the DSL element does not include these default values, therefore, you cannot query these values in the program. The purpose is to parse the manifest content only when necessary (during construction.