Android-gradle-simple introduction-5: build type
By default, the Android plug-in automatically creates a debug and a release version application for the project. The differences between the two versions are mainly reflected in the debugging functions of non-development machines and the APK signature method. The debug version uses a key created with a public name/password for signature (in this way, you do not need to prompt you to enter the password during building ). The release version will not be signed during construction, but will be executed later.
You can use the BuildType object in gradle for configuration. By default, two BuildType instances are created, one is debug and the other is release. The Android plug-in allows you to customize these two instances. Of course, you can also create other build types. The configuration is completed by the DSL buildTypes:
android { buildTypes { debug { applicationIdSuffix ".debug" } jnidebug.initWith(buildTypes.debug) jnidebug { packageNameSuffix ".jnidebug" jniDebuggable true } }}The above code completes the following Configuration:
1. Configure the default debug Build Type
Set the registration for the debug version <应用id> . Debug to install both the debug and release versions on the device.
2. Create a New BuildType named jnidebug, and configure it as a copy from debug Build Type.
Configure jnidebug to enable the JNI component of the debug version and add a different package name suffix.
It is very easy to create a new Build Types. You only need to add a new element by calling initWith or using a closure under buildTypes. The following table lists configurable attributes and default values:
Attribute: Default Value of debug version: release or default value of other versions
Debuggable true false
JniDebuggable false
RenderscriptDebuggable false
RenderscriptOptimLevel 3 3
ApplicationIdSuffix null
VersionNameSuffix null
SigningConfig android. signingConfigs. debug null
ZipAlignEnabled false true
MinifyEnabled false
ProguardFile N/A (set only)
ProguardFiles N/A (set only)
With these attributes, Build Types can also be used to configure code and resource files. For each Build Type, a new corresponding sourceSet will be created, and this sourceSet uses a default path src/ /. This means that the Build Type name cannot be main or androidTest (this is forced by the plug-in), and each Build Type name must be unique.
Like other source sets, the source set path in Build Type can also be configured.
android { sourceSets.jnidebug.setRoot('foo/jnidebug')}
In addition, for each Build Type, a new assemble The task is created. I have already talked about assembleDebug and assumerelease tasks. Here we can explain the sources of these two tasks. when debug and release Build Types are pre-created, their corresponding assemble tasks will also be created together.
The above build. gradle code snippet also creates an assembleJnidebug task. The assemble task also adds dependencies on the assembleJniDebug task, just as it depends on the assembleDebug and assumerelease tasks.
TIPS: You can use the gradle aJ command to run the assembleJnidebug task.
Possible scenarios:
Permissions used only in debug mode, not in release mode.
Different implementations are used in debug.
Debug mode uses different resources (for example, when the value of a resource depends on the signature)
The code/resource file in BuildType will be processed as follows:
Manifest configuration will be merge to app manifest
The code will not be used by merge and will be used as another code directory (source folder ).
The resource file overwrites the resource file in the same name main.
