Summary of daily development skills of Gradle

Gradle is the default build system in Android Studio. Gradle uses Groovy as the main scripting language. The build.gradle file of our app project and the build.gradle file in the APP Moudle is a Groovy class. Next, let me introduce the basic functions and advanced techniques of Gradle.

Basic Usage

 apply plugin: 'com.android.application'   
 
 android {
 compileSdkVersion 26
    buildToolsVersion "26.0.0"  
 defaultConfig {
        applicationId "com.renny.gradletest"  
 minSdkVersion 17
 targetSdkVersion 26
 versionCode 1
 versionName "1.0"  
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"  
 }
 buildTypes {
 release {
            minifyEnabled false  
            proguardFiles getDefaultProguardFile( 'proguard-android.txt' ), 'proguard-rules.pro'  
 }
 }
 } 
 
 dependencies {
    compile fileTree(dir: 'libs' , include: [ '*.jar' ])
    androidTestCompile( 'com.android.support.test.espresso:espresso-core:2.2.2' , {
        exclude group : 'com.android.support' , module: 'support-annotations'  
 })
    compile 'com.android.support:appcompat-v7:26.+'  
    compile 'com.android.support.constraint:constraint-layout:1.0.2'  
    testCompile 'junit:junit:4.12'  
 }

The code above is the build.gradle file in the default module created by the studio when the Android project is just built. The Gradle version used is 2.3.3. Most of the Gradle function configurations are also implemented in this file.

apply plugin:: is used to specify which plugin to use. Common values ​​in development are

'com.android.application': Android APP plug-in (the packaged file is .apk file)

'com.android.library': Android library plug-in (the packaged file is .aar file)

'java': ordinary java plug-in (packaged as a .jar file)

android{} is used to specify the relevant properties of the Android packaging plug-in, which contains the following nodes

compileSdkVersion(apiLevel): Set the Android version used for compilation

buildToolsVersion(buildToolsVersionName): Set the version of the build tool used when compiling

defaultConfig: Set some default properties. The available properties are the sum of buildTypes and productFlavors. (productFlavors is not included in the default file and will be introduced later.)

buildTypes: Configure the build type, which can generate different types of packages. The most common ones are debug and release. Of course, you can add N more.

productFlavors: Configure different styles of APP. On the basis of buildTypes, each type of APP can have different styles. Therefore, the number of APKs that can be printed is buildTypes multiplied by productFlavors. The variable name of the build is productFlavors+buildTypes.

Dependencies: Configure dependencies. This is definitely the most convenient part after switching from Eclipse to Studio. Various external dependencies can be handled with one line of code without manually downloading dependency packages.

Here compile fileTree(dir: 'libs', include: ['*.jar']) means to depend on all jar files in the libs directory.

Advanced Usage

Well, the basic configuration above is just a simple usage of Gradle. In fact, we can use Gradle to do a lot of tricks.

manifest dynamic configuration

Many third-party SDKs require you to configure some key information in AndroidManifest.xml. Take Umeng Push as an example:

 <meta-data
 android:value= "YOUR_APP_KEY"   
 android: name = "UMENG_APPKEY" />

But the keys of your different test packages and official packages are different, so you can modify them like this:

 <meta-data
    android: name = "UMENG_APPKEY"  
    android:value= "${UMENG_APPKEY}" />

Then add different information to each version in productFlavors, so that the appkey used by different packages you type will be different.

 manifestPlaceholders = [UMENG_CHANNEL: "0" ,
               UMENG_APPKEY : "123456789" ]

Not only can these custom metadata be dynamically configured, but also the android:icon, android:label and other tags can be modified, so that different packages can have different icons, which is convenient for distinguishing them.

Moudle dynamic dependency

In a componentized app, we may need to depend on different components in the test package and the production package. For example, the test environment needs a debug module, but the production environment does not. Suppose productFlavors is as follows, and the debug module name is module-test.

 productFlavors {
 ceshi{
 }
 publish{
 }
 }

Then you can depend on the test module in dependencies:

 ceshiCompile project( ':module-test' )

The same buildTypes are also applicable, both can be used together or separately:

 debugCompile project( ':module-test' ) ceshidebugCompile project( ':module-test' )

Reading variables in code

The above functions are all configured separately by gradle, but we often have different requirements for different build packages that need to be reflected in the code: log printing, Toast, etc.

Although the BuildConfig.DEBUG field can be used for judgment, we can use buildConfigField to pass custom values ​​to the code. For example, different build packages require different API addresses starting with Host, different https certificate paths, etc. The usage is:

 buildConfigField 'type' , 'name' , '"vaule"'  

for example:

 defaultConfig { 
 
 buildConfigField 'String' , 'author' , '"renny"'   
 
 }

The above is added to defaultConfig, and adding it to buildTypes or productFlavors will result in different values ​​in different build versions. If you configure different applicationIds, you can install different build versions of apps on the same phone at the same time.

 productFlavors {
 ceshi{
        applicationId "com.renny.test"  
       buildConfigField "String" , "API_TEST" , "http://test.renny.com/android"  
 }
 publish{
        applicationId "com.example.publish"  
      buildConfigField "String" , "API_PUBLISH" , "http://publish.renny.com/android"  
 }
 }

After the above introduction, you may find that buildTypes and productFlavors are very similar in definition, but the difference is that changing buildType will not change the application code, they just handle different things, you can get more technical details through buildType (for example: build optimization, log level, etc.), but the content of the app will not change, on the contrary, using productFlavor configuration can change the content of the app (ps: the content can be imagined as a package, buildType cannot change the applicationId).

Gradle tasks

Gradle tasks are suitable for completing some tedious and error-prone repetitive manual work, such as batch modification, copying, and renaming files.

For example, the applicationVariants.all task can set various properties for each build version, such as changing the name of the APK generated by each build version:

 applicationVariants. all { variant ->
       variant.outputs.each { output ->
 output .outputFile = new File(
 output .outputFile.parent,
                   ( "app-${variant.buildType.name}" + "-" + new Date ().format( 'yyyyMMdd' ) + ".apk" ).toLowerCase())
 }
 }

By default, gradle will match and generate a build version of each productFlavors*buildTypes. If you want to skip some of them, you can do this:

variantFilter { variant ->
   if (variant.buildType. name .equals( 'release' )) {
        variant.setIgnore(!variant.getFlavors().get(1). name .equals( 'ceshi' ));
 }
    if (variant.buildType. name .equals( 'debug' )) {
        variant.setIgnore(variant.getFlavors().get(1) .name .equals( 'ceshi' ));
 }
 }