Android Gradle Basic Configuration in the Gradle Series

Through the previous articles, you have learned the basic knowledge of Gradle and the knowledge related to Gradle plugins. Please read the following articles about Gradle and its plugin-related knowledge:

In the previous article, you learned about the configuration methods of the Android Gradle Plugin. I remember when I first encountered the build.gradle configuration file in Android, I was confused and didn't know the specific meanings of each configuration item. This article will introduce some of the most basic configurations in Android development. If you have any doubts in this regard, I believe this article will be helpful to you.

Default Configuration
Configuring Signing Information
Building Application Types
Using ProGuard
Enabling zipalign Optimization

Default Configuration#

defaultConfig is a configuration block in the Android Gradle configuration file. The type of defaultConfig is ProductFlavor. If there is no custom ProductFlavor, the default ProductFlavor is used to configure the Android project. The following are some of the configuration properties in defaultConfig:

// Default ProductFlavor configuration block
defaultConfig {
    // Configure the package name of the app
    applicationId "com.manu.base"
    // Configure the minimum supported Android system version for the app. The following two configurations of minSdkVersion are equivalent
    minSdkVersion 19
    <!--minSdkVersion 'KitKat'-->
    // Configure the Android SDK on which the app is based
    targetSdkVersion 26
    // Configure the internal version number of the app, which is generally used for version upgrades
    versionCode 1
    // Configure the external version number of the app, which is displayed to users
    versionName "1.0"
    // Configure the Runner used for unit testing
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    // Configure the package name of the test app
    testApplicationId "com.manu.androidgradleproject.test"
    // Use the specified signing file configuration
    signingConfig signingConfigs.release
}

Configuring Signing Information#

Configuring signing information for the app is beneficial in preventing the app from being maliciously tampered with. Signing ensures the uniqueness of the app and only allows the installation of subsequent upgrade packages that use the same signature. After creating the signing certificate file, if you do not configure it, you must specify the password and alias of the signing file every time you package it. Generally, when developing an app, different signing files are configured in debug and release modes.

Step 1: Create a signing certificate file. Fill in the relevant information as shown in the figure below:

Step 2: Use the signConfigs configuration block to configure the relevant information of the created signing certificate file as follows:

// Signing file configuration
signingConfigs {
    release{
        // Signing certificate file
        storeFile file("project.jks")
        // Signing certificate file password
        storePassword "111111"
        // Signing certificate alias
        keyAlias "project_jks"
        // Key password in the signing certificate
        keyPassword "111111"
    }
    debug{
        // By default, the signing in debug mode is configured as the debug signing file certificate automatically generated by the Android SDK
        // Default signing file location: .android/debug.keystore
    }
}

Step 3: Use the signing file configuration. In defaultConfig{} under android{}, use the above configuration as follows:

defaultConfig {
    // ...
    // Use the specified signing file configuration
    signingConfig signingConfigs.release
}

In addition to configuring in defaultConfig{}, you can also configure different signing files in debug or release mode separately. You can configure them separately in buildTypes{}. The specific configuration is as follows:

buildTypes {
    release {
        signingConfig signingConfigs.release
        // ...
    }
    debug{
        signingConfig signingConfigs.debug
        // ...
    }
    
    // ...
}

Building Application Types#

Android Gradle has two built-in build types: debug and release. The difference between the two is that the former is generally used in debugging mode, and the latter is generally used in formal release mode. They are the same in other aspects. So how to add new build types? You can directly add the types to be added in buildTypes{}. The buildTypes parameter accepts a domain object, and the added build types are all BuildType, so you can configure the build types through the relevant properties of BuildType. The following are some common configuration properties of BuildType:

buildTypes {
    release {
        // ...
    }
    debug{
        // Configure signing
        signingConfig signingConfigs.debug
        // Configure the suffix of applicationId under the current build type. The package name of the generated Apk will be based on the applicationId with the suffix added
        applicationIdSuffix '.debug'
        // Configure whether to generate a debuggable Apk
        denbuggable true
        // Configure whether to generate an Apk for debugging jni (c/c++) code
        jniDebuggable true
        // Whether to enable ProGuard obfuscation
        minifyEnabled true
        // Configure whether to automatically split multiple dex when the number of methods in the program exceeds 65535
        multiDexEnabled true
        // Configure the ProGuard configuration file used for obfuscation. Multiple obfuscation files can be configured
        proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
        // Configure whether to automatically clean up unused resources. The default is false
        shrinkResources true
        // Enable zipalign optimization (see below)
        zipAlignEnabled true
    }
}

After adding a new build type in buildTypes{}, Android Gradle will automatically generate a SourceSet, and the Apk will be built from the corresponding SourceSet. Remember that the name of the new build type cannot be the same as the existing one. At the same time, add source code directories and resource files, etc. for the newly created build type under the src directory. At the same time, the Android Gradle plugin will generate the corresponding assemble task for building projects of this type. For example, release corresponds to assembleRelease, and executing this task will generate the corresponding Apk.

Using ProGuard#

Code obfuscation mainly increases the difficulty of decompilation. When releasing the official version of the app, code obfuscation is generally performed. In fact, the Android SDK already provides default obfuscation files, which are located in tools/proguard under the Android SDK. The content mainly includes some basic content that cannot be obfuscated. The two default obfuscation files are as follows:

// No optimization
proguard-android.txt 
// Optimized
proguard-android-optimize.txt

So how to use obfuscation? In the corresponding build type under buildTypes{}, set minifyEnabled to true to enable obfuscation, and then configure the specific obfuscation file, as follows:

buildTypes {
    release {
        // Enable obfuscation
        minifyEnabled false
        // Configure obfuscation file
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
   // ...
}

Enabling zipalign Optimization#

zipalign is a tool provided by Android to optimize the arrangement of apk files, which can improve the efficiency of system and application operation to a certain extent, read resources in the apk faster, and reduce memory usage. To enable zipalign optimization, just enable zipalign optimization under the corresponding build type in buildTypes{}, as follows:

buildTypes {
    release {
       // Enable zipalign optimization
       zipAlignEnabled true
       // ...
    }
   // ...
}

This article introduces some common configuration items in Android development. If you find it helpful, you can follow or like to support it.