Android — Gradle Tutorial

This is the third day of my participation in the November Gwen Challenge. Check out the details: the last Gwen Challenge 2021

preface

In the previous article, THE basic configuration and multi-channel packaging of AGP were explained, and AGP will be further explained in this article.

1, the Android {}

Android {}, other nodes introduced by AGP:

• resValue
• buildConfigField
• adbOptions

These nodes are not created by default and need to be manually defined by the developer. So what should these nodes do for each other?

1.1 resValue

Look at this name and it feels like it’s resource specific, so let’s get started with the code.

android{ ... Slightly defaultConfig {... Slightly resValue'string'.'aaa'.'aaa'. Slightly} flavorDimensions'channel'
    productFlavors {
        baidu {
            dimension 'channel'
            //resValue 'string', 'app_name', 'custom name' // There cannot be duplicate resource nodes
            resValue 'string'.'bbb'.'nnnn'
        }
        ali {
            dimension 'channel'}}... Slightly}Copy the code

In combination with yesterday’s content, it can be seen that the attribute resValue is defined in defaultConfig and Baidu in custom product flavor respectively. Now build and compile to see the effect.

As is shown in

When the build is successful, we open the contents of the successful build folder to see: the string resources we just created with the keyword resValue and helped us to build in the resource file. The comments also indicate which product dimension the generated resources were created from. Since it is in the resource file, it should work fine. Now let’s try it out

As is shown in

When the build is successful, the resources generated by Gradle are still available. Since Gradle can generate resources, can it modify them? Just try it out!

As is shown in

On the right is the value of the resource inside the string, the content inside the string. And on the left is what we’re going to change, so let’s run the build and see what happens.

When building a project, an error is reported. If you look carefully at the console, it means that duplicate resources cannot be defined by resValue.

Now summarize what this resValue does

• Use resValue to add resource file properties to the current build product.
• resValue ‘string’, ‘name’, ‘value’
  • String indicates the type of the resource label. Name: name of the resource attribute. Value: indicates the corresponding attribute value.
  • Note that name cannot be overwritten if it already exists.
• Different product flavors can add their own resValues, which can be added in defalutConfig{} if all product flavors are added.

1.2 buildConfigField

• Use buildConifgField to modify the types in BulidConfig for the product.
• BuildConfig is a Java class that is automatically generated at product build time and stores static constants that can be used directly after compilation.
• buildConfigField ‘String’, ‘fieldName’, ‘value’
  • String represents a String type, which can be any other Java type, but note that this is a text substitution. So, for other types, you can use the full class name approach.
  • FiledName indicates the attribute name, and value indicates the corresponding value. If value is a string, you need to add double quotation marks

So much for the concept, go straight to the code and see the effect.

android {
    compileSdkVersion 30defaultConfig { ... Slightly buildConfigField'Boolean'.'DEBUG'.'true'
        buildConfigField 'int'.'taskId'.'16'
        buildConfigField 'String'.'BASE_URL'.'"http:www.baidu.com"'. ProductFlavors {baidu {dimension'channel'
// resValue 'string', 'app_name', 'custom name' // There cannot be duplicate resource nodes
            resValue 'string'.'bbb'.'nnnn'
            buildConfigField  'String'.'CHANNEL_VALUE'.'"BAIDU"'
        }

        ali {
            dimension 'channel'}}}Copy the code

BuildConfigField keyword is used in defaultConfig and custom product only baidu respectively. Then we build and see the effect.

As is shown in

The system defines in BulidConfig the properties we created in Gradle with the buildConfigField keyword. The corresponding annotation also indicates which product dimension it comes from. BulidConfig attributes are defined in BulidConfig, so they can also be used in the logic code.

Effect perfect operation, to this seems to master a multi-channel packaging access to the channel number related knowledge points. We can also define BaseUrl in Gradle when we request interfaces.

I don’t want to write all my BaseUrl information in Gradle in the project directory. What should I do if I want to place it in a separate file?

This brings us to what we’ve learned before: script plug-ins

So make your own script:

MyConfig.gradle

ext{
     DEBUG = true
     BASE_URL="https://juejin.cn/user/2357827986264942"
     taskId=15
     LOGIN_URL=BASE_URL+"/xx/xx/login"
}
Copy the code

Here I changed the BASE_URL to my nuggets home page and made some other modifications. Then I introduced this script into the project and changed the previous fetching method to get:

plugins {
    id 'com.android.application'
    id 'kotlin-android'
}

apply from:'.. /MyConfig.gradle'

android {
    compileSdkVersion 30

    defaultConfig {
        applicationId "com.hqk.gradledemo04"
        minSdkVersion 21
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"

        resValue 'string'.'aaa'.'aaa'

        buildConfigField 'Boolean'.'DEBUG'."${DEBUG}"

        buildConfigField 'int'.'taskId'."${taskId}"

        buildConfigField 'String'.'BASE_URL'."\"${BASE_URL}\""

        buildConfigField 'String'.'LOGIN_URL'."\"${LOGIN_URL}\""}}Copy the code

The local script plug-in was introduced, and then the property values were changed to dynamically fetched. Now recompile the build to see the effect.

Look at that. It worked perfectly.

1.3 adbOptions

In Android {}, you can add ADB Settings for build types. Hands-on code:

android{ ... slightly// Adb action options
    adbOptions {
        installOptions '-r'.'-s'.'-d'
        //-l, -t, -d, -g
        -d allows degraded installation
        // -g should have access to all runtimes

        Adb install has l, r, t, s, d, and g options.
        // -l: lock the application
        // -r: replaces existing applications to force installation
        // -t: allows test packages
        // -s: installs the application onto the SD card
        -d: Allows a degraded install, i.e. the version of the application is lower than the version on the phone
        // -g: grants all run-time permissions to the application}... Slightly}Copy the code

This is very simple, just a few configurations, can follow multiple, each function is written in a comprehensive note. Readers can try it out for themselves.

conclusion

By now, this chapter is almost finished, and AGP configuration is almost finished. From the next chapter, WE will start to explain AGP combat related.