Configuration method of Gradle construction process in Android App development

The use of the Android or Java plug-ins in the build file automatically creates a series of tasks that can be run.
In Gradle, there are tasks under the following 1 default contract:
1. assemble
This task includes all package related tasks in the project, such as jar package in java project and apk package in Android project
2. check
This task includes all validation-related tasks in the project, such as the task of running tests
3. build
This task includes assemble and check
4. clean
This task will empty all output of the project and delete all packets typed in the assemble task
The assemble, check, and build tasks don't actually do anything, they just provide a hook for the plug-in, and the real thing is done by the plug-in.
This way, developers don't need to care whether I'm running an java project or an Android project, or which gradle plug-ins I'm using, because I can invoke these agreed tasks to complete the build.
For example, using findbugs plug-in will create a new task, and make check task depend on this new task, so that this new task will be executed every time check task is executed.
Execute on the command line

gradle tasks 

< /pre > Will list all the major tasks. If you want to see all the tasks and their dependencies, you can run: < pre name="code" class="java" > gradle tasks --all
Note: Gradle will automatically check the input and output of 1 task. For example, if you run build tasks twice in a row, Gradle will report that all tasks are newly run and do not need to be run again. In this way, even if there is interdependence between tasks, it will not lead to repeated execution.
Common Tasks for Java Projects
Java plugin mainly creates two tasks:
1. jar
The assemble task will depend on the jar task, which is the task responsible for typing jar packets. The jar task itself depends on many other tasks, such as the classes task, and the classes task compiles the java code
2. test
The check task relies on the test task, which runs all the tests. The test code was compiled using the testClasses task, but we hardly need to run the testClasses task manually because the test task has added a dependency on it.
Usually, we just need to run assemble and check tasks.
To see all the tasks provided by the java plug-in and their dependencies, click on this [link] (http://gradle.org/docs/current/userguide/java_plugin. html)
Common Tasks for Android Projects
Like other gradle plug-ins, Android plug-ins also provide 1 default task, such as assemble, check, build, clean, and it also provides 1 unique task, such as:
1. connectedCheck
Run those check tasks that need to be performed on the real machine or emulator, which will run on all connected devices in parallel
2. deviceCheck
Use APIs to connect remote devices to perform checks. Mainly used on CI (Continuous Integration) services.
Both tasks above perform the assemble and check tasks. It is necessary to add these two new tasks to ensure that we can run those inspection tasks that do not need to connect devices.
Note: The build task does not depend on deviceCheck or connectedCheck
An Android project typically has at least two outputs: debug apk and release apk. There are two tasks in the corresponding gradle that can output different apk:

assembleDebug assembleRelease

These two tasks will depend on other tasks to build an apk. The assemble task relies on both tasks, and invoking the assemble task generates two types of apk.

Tip: Gradle supports using camel-style abbreviations instead of task names on the command line, such as:

gradle aR 

Equivalent to

gradle assembleRelease 

As long as there is no abbreviation for other tasks, it is also 'aR'
check-related task dependencies:

check depends on lint connectedCheck relies on connectedAndroidTest and connectedUiAutomatorTest (not yet implemented) deviceCheck relies on the tasks provided by plug-ins that implement test extensions

Finally, the Android gradle plug-in also provides install and uninstall tasks for installing and uninstalling apk

Configuration of custom build process manifest
The Android Gradle plug-in provides a large number of DSL custom build processes, and the following explains how to configure manifest in gradle.
DSL provides the ability to configure the following Manifest entries:

minSdkVersion targetSdkVersion versionCode versionName applicationId (more convenient and effective package name-[reference] (http://tools. android. com/tech-docs/new-build-system/applicationid-vs-packagename)) Test the package name of app Instrumentation test runner

Example:

android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName "2.0" 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
} 

The defaultConfig element in the android element is where we configure Manifest. Earlier versions of the Android plug-in used packageName to configure the packageName property in manifest, starting with 0.11. 0, using applicationId instead of packageName. This eliminates the confusion between the package name of the application (which is actually the id of the application) and the package name of the java.

What is more powerful is that the configuration described in the build file can be dynamic, for example, the version name can be obtained from the file or custom logic.

def computeVersionName() { 
  ... 
} 
 
 
android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName computeVersionName() 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
} 

Note: Do not use the getter method name in the scope as the function name. For example, calling getVersionName () in the defaultConfig {} scope will automatically call defaultConfig. getVersionName () instead of calling the custom method.
If the value of a property is not set using DSL, the property will use some default values. The following table shows how to handle the default values.
Default value in attribute name DSL object default value

Property Name	Default value in DSL object	Default value
versionCode	-1	value from manifest if present
versionName	null	value from manifest if present
minSdkVersion	-1	value from manifest if present
targetSdkVersion	-1	value from manifest if present
applicationId	null	value from manifest if present
testApplicationId	null	applicationId + “.test”
testInstrumentationRunner	null	android.test.InstrumentationTestRunner
signingConfig	null	null
proguardFile	N/A (set only)	N/A (set only)
proguardFiles	N/A (set only)	N/A (set only)

The values in Column 2 are important if you want to use custom logic to query these properties in an build script. For example, you can write the following code:

if (android.defaultConfig.testInstrumentationRunner == null) { 
  // assign a better default... 
} 

If the value of the attribute is still null, the default values in Column 3 will be used at build time, but these default values are not included in the DSL element, so you cannot query these values in the program. The purpose of this is to parse manifest content only when necessary (build time).