Android Gradle Basic Configuration in the Gradle Series

Learned about the basics of Gradle and Gradle plugin-related knowledge in the previous articles. Please read the following articles about Gradle and its plugin-related knowledge:

In the previous article, we learned about the configuration methods of the Android Gradle plugin. I remember when I first started working with 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. defaultConfig is of type ProductFlavor. If no custom ProductFlavor is defined, 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 version for the app. The two configurations of minSdkVersion below are equivalent
    minSdkVersion 19
    <!--minSdkVersion 'KitKat'-->
    // Configure the Android SDK version used for developing the app
    targetSdkVersion 26
    // Configure the internal version code of the app, which is generally used for version upgrades
    versionCode 1
    // Configure the external version name 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 the signing information of the app is beneficial to prevent 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 don't configure it, you will need to specify the password, alias, etc. of the signing file every time you build the package. Generally, when developing an app, different signing files are configured for the 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 signingConfigs 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 key 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{}. For example:

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 you want to add in buildTypes{}. The buildTypes parameter accepts a domain object, and the added build types are all BuildType. Therefore, 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 the signing
        signingConfig signingConfigs.debug
        // Configure the suffix of applicationId under the current build type. The package name of the generated Apk will have the suffix added to the applicationId
        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 files when the number of methods in the program exceeds 65535
        multiDexEnabled true
        // Configure the proguard obfuscation configuration file. 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 new build types in buildTypes{}, Android Gradle will automatically generate a SourceSet for each build type, and the Apk will be built from the corresponding SourceSet. Remember that the name of the new build type must not be the same as the existing ones. At the same time, add source code directories and resource files, etc., for the newly created build type under the src directory. When creating a new build type, the Android Gradle plugin will also generate the corresponding assemble task for building the project of that type. For example, release corresponds to assembleRelease. 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 code 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 the 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 resources in apk files, which can improve the efficiency of system and app operation to a certain extent, read resources in 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.