By default, the Android plugin automatically builds a debug and release version of the app for your project. The differences between these two versions are mainly in the debug function on non-development machines and the way the APK is signed. The debug version is signed with a key created with the public Name/password (so you don't need to prompt for a password when you build it). The release version is not signed at the time of construction, but is done later.
This can be configured using the BuildType object in Gradle. By default, 2 instances of BuildType are created, one debug, one release. The Android plugin allows you to customize these two instances, and of course you can create additional build type. The configuration is done by buildtypes this DSL:
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 debug version to register for < app Id>.debug, so you can install both the debug and release versions on your device.
2. Create a new BuildType, the name is Jnidebug, and configure it to be copied from the debug Build Type.
Configure Jnidebug to turn on the JNI component of the debug version and add a different package name suffix.
Creating a new build types is very simple, just need to add a new element under buildtypes by calling Initwith or using a closure. The following table is the properties that you can configure and the default values:
Attribute Debug version default release or other version default value
Debuggable true False
Jnidebuggable false False
Renderscriptdebuggable false False
Renderscriptoptimlevel 3 3
Applicationidsuffix NULL NULL
Versionnamesuffix NULL NULL
Signingconfig android.signingConfigs.debug NULL
Zipalignenabled false True
Minifyenabled false False
Proguardfile N/A (set only) n/A (set only)
Proguardfiles N/A (set only) n/A (set only)
These properties, Build types can also be used to configure code and resource files. For each build Type, a new corresponding Sourceset is created, and the Sourceset uses a default path Src/<buildtype the name >/. This means that the name of the build type cannot be either main or androidtest (this is enforced by the plugin), and the name of each build type must be unique.
As with 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<buildtype name > task will be created. I've talked about Assembledebug and assemblerelease tasks before, This explains the origins of the two missions. When debug and release Build types are pre-created, their corresponding assemble tasks are also created together.
The Build.gradle code fragment above also creates a Assemblejnidebug task, and the assemble task also adds a dependency on the Assemblejnidebug task, just as it relies on assembledebug and assemblerelease tasks.
Tip: You can use the Gradle AJ command to run the Assemblejnidebug task.
It might be a usage scenario:
The release mode is not used for permissions that are used in debug mode only.
Use different implementations when debugging
Debug mode uses different resources (such as when a resource's value depends on the signature)
The code/resource files in the BuildType will be processed as follows:
Manifest configuration will be merge into app manifest
The code will not be merge and will be used as another code directory (source folder)
The resource file overwrites the resource file in main with the same name
android-gradle-in layman-five: Build Type
