The configuration method of Gradle construction process in Android app development _android

When you use Android or a Java plug-in in a build file, you automatically create a series of tasks that you can run.
The Gradle has the following default contract tasks:
1. Assemble
This task contains all the packaging-related tasks in the project, such as Jar packs in Java projects, apk in the Android project
2. Check
This task contains all the validation-related tasks in the project, such as the task to run the test
3. Build
This task contains assemble and check
4. Clean
This task empties all of the project's output and deletes all the packages that were played in the assemble task
Assemble, check and build tasks do not actually do anything, they actually just provide a hook for plug-ins, and the real thing is done by Plug-ins.
In this way, developers don't have to worry about whether I'm running a Java project or an Android project, or what Gradle plug-ins I use, because I can call these agreed tasks to complete the build.
For example, using the FindBugs plugin creates a new task and makes the check task dependent on the new task, so that the new task will be executed each time the check task is executed.
Executing at the command line

Gradle Tasks 

</pre> will list all 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 automatically checks the input and output of a task. For example, running a build task twice in a row, Gradle will report that all the tasks are already up to date and don't need to run again. In this way, the task is interdependent and does not lead to repetitive execution.
Common tasks for Java projects
The Java plugin primarily creates two tasks:
1. Jar
The assemble task relies on the jar task, and the name is known to be responsible for the jar pack task. The jar task itself relies on many other tasks, such as the classes task, where the classes task compiles Java code
2. Test
The check task relies on the test task, which runs all the tests. The test code compiles with the Testclasses task, but we basically do not have to run the Testclasses task manually because the test task has added dependencies on it.
Normally, we just run assemble and check tasks.
Want to see all the tasks provided by the Java Plug-ins and their dependencies can point to this [link] (http://gradle.org/docs/current/userguide/java_plugin.html)
Common tasks for Android projects
Like other Gradle Plug-ins, the Android plug-in also provides some default tasks, such as Assemble,check,build,clean, and it also provides some of its own unique tasks, such as:
1. Connectedcheck
Run the 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 device execution checks. Mainly for CI (continuous integration) services.
Both of the above tasks perform assemble and check tasks. The new addition of these two tasks is necessary to ensure that we can run the inspection tasks that do not require connecting devices.
Note: The build task does not depend on Devicecheck or Connectedcheck
An Android project usually has at least two outputs: Debug apk and Release apk. There are two tasks in the corresponding gradle that can output different apk separately:

• Assembledebug
• Assemblerelease

These two tasks will depend on other tasks to build a apk. The assemble task relies on both tasks, and calling the assemble task generates two kinds of apk.

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

Gradle AR 

Equal to

Gradle Assemblerelease 

As long as there is no other task the abbreviation is also ' AR '
Check dependencies for tasks related to:

• Check dependency Lint
• Connectedcheck relies on connectedandroidtest and connecteduiautomatortest (not yet implemented)
• Devicecheck relies on the tasks provided by Plug-ins that implement the test extension

Finally, the Android Gradle plug-in also provides install and uninstall tasks to install and uninstall APK

Customizing the configuration of the build process manifest
the Android Gradle plug-in provides a large number of DSLs to customize the build process, and the following explains how to configure manifest in Gradle.
The 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 Package name for app
• Instrumentation Test Runner

Example:

Android { 
  compilesdkversion 
  buildtoolsversion "19.0.0" 
 
 
  defaultconfig { 
    Versioncode 
    Versionname "2.0" 
    minsdkversion 
    targetsdkversion} 
 

The Defaultconfig element in the Android element is where we use to configure manifest. Earlier versions of the Android plug-in used PackageName to configure the PackageName properties in manifest, starting with 0.11.0 and using ApplicationID instead of PackageName. This eliminates the confusion between the application's package name (which is actually the application ID) and the Java package name.

More powerful is that the configuration described in the build file can be dynamic, such as getting a version name from a file or custom logic.

Def computeversionname () { 
  ... 
} 
 
 
Android { 
  compilesdkversion 
  buildtoolsversion "19.0.0" 
 
 
  defaultconfig { 
    Versioncode 
    Versionname computeversionname () 
    minsdkversion 
    targetsdkversion 
  } 

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 invoke Defaultconfig.getversionname (). The custom method is not invoked.
If the value of a property does not use a DSL setting, this property will use some default values, and the following table shows the process of default values.
Property name default value in DSL object

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)

If you want to use custom logic to query these properties in the build script, the values in the second column are important. For example, you can write the following code:

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

If the value of the property is still null, the default value of the third column is used at build time, but the DSL element does not contain these defaults, so you cannot query the values in the program. The purpose of this is to parse the manifest content only when necessary (at build time).