Gradle Learning: the basis for custom building and gradle Building

Gradle Learning: the basis for custom building and gradle Building
1. Configure the Manifest File

You can configure applicationId, minSdkVersion, targetSdkVersion, versionCode, and versionName directly by building a file instead of the manifest file. In addition, we can control the following attributes:

TestApplicationId: applicationId testInstrumentationRunner: name of the JUnit test runner for the instrument test APK, used to run the signingConfig: proguardFiles II. BuildConfig class

After the SDK version is upgraded to 17, the build tool generates a class called BuildConfig, which contains a DEBUG constant that sets values according to the build type. If you only want to run part of the code during debugging, such as logging, DEBUG is very useful. You can use Gradle to expand the file so that different constants can be created in debug and release:

   buildTypes {        debug {           buildConfigField  "String",  "API_ URL", "\"https:// test. example. com/ api\""                         buildConfigField "boolean", "LOG_ HTTP_ CALLS", "true"           minifyEnabled false           proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }        release {            buildConfigField  "String",  "API_ URL", "\"https:// test. example. com/ api\""                          buildConfigField "boolean", "LOG_ HTTP_ CALLS", "false"            minifyEnabled false            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }    }

The string value must be enclosed in double quotation marks to generate a string in the actual sense. After adding buildConfigField, you can use BuildConfig. API_URL and BuildConfig. LOG_HTTP _ CILS in your Java code.

Recently, the Android tool development team has added a similar method to configure resource values:

   buildTypes {        debug {            resValue "string", "app_name", "ExampleDEBUG"        }        release {           resValue "string", "app_name", "Example"        }    }

Here, double quotation marks are not escaped, because the resource value is usually packaged as value = "" by default.

Iii. Scope of project configuration

Read this Code:

allprojects {      apply plugin:'com.android.application'      android {        compileSdkVersion  27        buildToolsVersion  "27.0.1"      }}

This code is valid only when all your modules are Androidapp projects, because you need to use the Android plug-in to obtain Android-specific settings.

A better way to implement this behavior isDefine values in the top-level Build File and apply them to the module.. Gradle allows you to add additional properties to a Project object. This means that any build. gradle file can define additional attributes. To add additional attributes, you must use the ext code block.

You can add an ext code block containing custom attributes to the top-level build file:

project.ext {    android = [            compileSdkVersion   : 27,            buildToolsVersion   : "27.0.1",            minSdkVersion       : 16,            targetSdkVersion    : 27,            versionCode         : 1,            versionName         : "1.0.0"    ]}

This section of code allows the Module layer build file to use rootProject to obtain attributes:

android {    compileSdkVersion rootProject.ext.android["compileSdkVersion"]    buildToolsVersion rootProject.ext.android["buildToolsVersion"]    defaultConfig {        minSdkVersion rootProject.ext.android["minSdkVersion"]        targetSdkVersion rootProject.ext.android["targetSdkVersion"]        versionCode rootProject.ext.android["versionCode"]        versionName rootProject.ext.android["versionName"]    }}

Iv. Project Properties

The ext code block in the preceding example is a way to define additional attributes. You can use attributes to dynamically customize the building process. There are many ways to define attributes. Here we only introduce three common methods:

Ext code block gradle. properties file-P command line parameters

ext {    local='Hello from build.gradle'}task printProperties  {     println local // Local extra property     println propertiesFile // Property from file     if (project. hasProperty(' cmd')) {         println cmd // Command line property     } }

Implementation of the gradle. properties file (in the same folder ):

propertiesFile = Hello from gradle.properties

We can define attributes in both top-level build files and module build files. If a module defines an attribute that already exists in the top-level file, the new attribute will directly overwrite the original attribute.

5. Default task

If you run Gradle without specifying any task, it runs the help task and prints information on how to use Gradle. The help task is set as the default task. You can override the default task and add a common task or even multiple tasks each time you run Gradle without explicitly specifying the task.

Add a line to the top-level build. gradle file to specify the default task:

defaultTasks 'clean', 'assembleDebug'

Now, when you run GradleWrapper without any parameters, it runs clean and assembleDebug. By running the tasks task and formatting the output, you can clearly see which tasks are set as default tasks.

$ gradlew tasks | grep "Default tasks" Default tasks: clean, assembleDebug