Personal wechat public number practice, welcome to pay attention to exchange.

Gradle plugins Gradle plugins Gradle plugins Gradle plugins

  • First introduction to Gradle series
  • Gradle: Groovy Basics
  • Gradle series build script basics
  • Gradle series understanding Gradle tasks
  • Gradle plugin for Gradle series
  • Gradle series of Java Gradle plug-ins
  • Gradle series of Android Gradle plugin
  • Gradle series Android Gradle base configuration
  • Android Gradle advanced Configuration
  • The Gradle series builds Maven private server libraries from scratch

In the last article, we learned about the following configuration methods of Android Gradle plug-in. I remember that at the beginning of contact with Android build. Gradle configuration file is also confused, do not know the specific meaning of each configuration item. This article will cover some of the most basic features of Android development, so if you’re wondering, this article will be a good one for you

  1. The default configuration
  2. Configuring Signature Information
  3. Building application types
  4. Using confusion
  5. Enable zipalign optimization

The default configuration

DefaultConfig is a configuration block in the Android Gradle configuration file. DefaultConfig is of type ProductFlavor. The default ProductFlavor is used to configure the Android project. The following configuration properties in defaultConfig are introduced:

// Default ProductFlavor configuration block
defaultConfig {
    // Configure the App package name
    applicationId "com.manu.base"
    // The following two minSdkVersion configurations are consistent with the lowest supported Android version of the App
    minSdkVersion 19<! --minSdkVersion'KitKat'-->
    // Configure which Android SDK the App is developed on
    targetSdkVersion 26
    // Set the internal version number of the App. It is generally used for version upgrade
    versionCode 1
    // Set the external version number of the App for users to view
    versionName "1.0"
    // The Runner used to configure unit tests
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    // Configure the package name of the test App
    testApplicationId "com.manu.androidgradleproject.test"
    // Use the specified signature file configuration
    signingConfig signingConfigs.release
}
Copy the code

Configuring Signature Information

The advantage of configuring App signature information is to prevent the App from being maliciously tampered. Signature ensures the uniqueness of the App and only subsequent upgrade packages with the same signature can be installed properly. After creating a signature file, you must specify the password and alias of the signature file each time if you do not configure the package. Generally, App development configures different signature files in denug and Release mode.

Step 1: Create the signature certificate file and fill in the relevant information as shown below:

Step 2: Use the signConfigs configuration block to configure the information about the created signature certificate file:

// Signature file configuration
signingConfigs {
    release{
        // Sign the certificate file
        storeFile file("project.jks")
        // Sign the certificate file password
        storePassword "111111"
        // Signature certificate key alias
        keyAlias "project_jks"
        // The key password in the signature certificate
        keyPassword "111111"
    }
    debug{
        // By default, signatures in debug mode are configured as the Debug signature file certificate automatically generated by the Android SDK
        // The default signature file location is.android/debug.keystore}}Copy the code

Step 3: Use the signature file configuration. Use the above configuration in Android {} defaultConfig{} as follows:

defaultConfig {
    / /...
    // Use the specified signature file configuration
    signingConfig signingConfigs.release
}
Copy the code

In addition to defaultConfig{}, different signature files can be configured in denBug or release mode respectively, and can be configured separately in buildTypes{} as follows:

buildTypes {
    release {
        signingConfig signingConfigs.release
        / /...
    }
    debug{
        signingConfig signingConfigs.debug
        / /...
    }
    
    / /...
}
Copy the code

Type of build application

Android Gradle has two built-in build types: debug and Release. The former is usually used in the debug state, and the latter is usually used in the official release state. Otherwise, it is the same. BuildTypes {} takes a domain object as an argument, and all buildTypes added are buildTypes, so you can configure buildTypes with BuildType attributes. Here are some common configuration properties for BuildType:

buildTypes {
    release {
        / /...
    }
    debug{
        // Configure the signature
        signingConfig signingConfigs.debug
        // Set the suffix for applicationId under the current build type. The package name that builds the Apk will be suffixed with applicationId
        applicationIdSuffix '.debug'
        // Configures whether to generate an Apk for debugging
        denbuggable true
        // Configures whether to generate an Apk for debugging JNI (C/C ++) code
        jniDebuggable true
        // Whether to enable proGuard obfuscation
        minifyEnabled true
        When the number of methods in the program exceeds 65535, whether to enable the function of automatically splitting multiple dex.
        multiDexEnabled true
        // Configure the proGuard obfuscation configuration file
        proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
        // Set whether to automatically clear unused resources. The default value is false
        shrinkResources true
        // Enable zipalign optimization (see below)
        zipAlignEnabled true}}Copy the code

When adding a new build type to buildTypes{}, Android Gradle automatically generates a SourceSet and the build Apk builds from the corresponding SourceSet. Remember that the name of the new build type cannot be the same as the name of the existing build type. Add source code directories and resource files to the SRC directory for the newly created build type. When the build type is created, the Android Gradle plugin also generates the assemble task for building that type of project. If the corresponding release is assembleRelease, this task generates the corresponding Apk.

Using confusion

Code obfuscation mainly increases the difficulty of decomcompiling. When releasing the official version of the App, code obfuscation is usually carried out. In fact, the default obfuscation file is provided under the Android SDK, and the specific location is under tools/ Progrard. The contents are mainly the most basic can not be confused, the two default obfuscation files are as follows:

/ / not optimized
proguard-android.txt 
/ / has been optimized
proguard-android-optimize.txt
Copy the code

To use obfuscation, set minifyEnabled to true for the corresponding build type in buildTypes{}, and then configure the specific obfuscation file as follows:

buildTypes {
    release {
        // Turn on obfuscation
        minifyEnabled false
        // Configure obfuscation files
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
   / /...
}
Copy the code

Enable zipalign optimization

Zipalign is a tool for sorting and optimizing APK files provided by Android, which can improve the running efficiency of the system and applications to a certain extent, read resources in APK faster, and reduce the use of memory. To enable Zipalign optimization, simply enable zipalign optimization under the corresponding build type in buildTypes{}, as follows:

buildTypes {
    release {
       // Enable zipalign optimization
       zipAlignEnabled true
       / /"
    }
   / /...
}
Copy the code

This article introduces some common configuration items in Android development.

You can follow the official account: Jzman-blog, to communicate and learn together.