Official Android Technical Documentation translation-Gradle Plug-In User Guide (6), androidgradle

Official Android Technical Documentation translation-Gradle Plug-In User Guide (6), androidgradle

I did not expect to translate this Gradle plug-in user guide for almost a month. But fortunately, at the second day, I finally completed the translation of the rest (in fact, the rest of the day is not a chapter ).

Let's start Chapter 6 today and Chapter 7 tomorrow.

This article is translated from the official Android Technical Documentation Gradle Plugin User Guide. The original address is http://tools.android.com/tech-docs/new-build-system/user-guide.

It is not easy to translate. For more information, see the source on the CSDN blog:

Http://blog.csdn.net/maosidiaoxian/article/details/42386877

For the first three chapters, see Gradle plug-in user guide (1-3).

For Chapter 4, see Gradle Plug-In User Guide (4).

For the fifth chapter, see Gradle Plug-In User Guide (5).

Translation is time-consuming. If you think the translation is still OK, please click "TOP" at the end of the article. I will be encouraged in spirit. Thank you. If any translation error occurs, please correct it.

Test Building a test application has been integrated into the application project. Therefore, there is no need to create a separate test project.
As mentioned above Main  SourceSetNext to androidTest SourceSetBy default, it is located in src/androidTest/
The sourceSet here is a tested apk which can be deployed on devices and tested using the Android testing framework. It can contain unit tests, instrumentation tests, and subsequent uiautomator tests. This
SourceSet should not contain AndroidManifest. xml because it is automatically generated.

Below are the values that can be used to configure the test application:

• TestPackageName
• TestInstrumentationRunner

• TestHandleProfiling

• TestFunctionalTest

As we can see earlier DefaultConfigObject Configuration:

Android {defaconfig config {testPackageName "com. test. foo" testInstrumentationRunner "android. test. InstrumentationTestRunner" testHandleProfiling true testFunctionalTest true }}

In the instrumentation node of the manifest in the test program, the value of the targetPackage attribute is automatically set to the package name of the tested application, even if it passes defaconfig config or Build TypeThe object has been customized. This is one of the reasons why manifest is automatically generated.

In addition, SourceSetYou can configure your own dependencies.
By default, the application and its own dependencies are added to the classpath of the test application. However, the following extensions can be used:

Dependencies {androidTestCompile 'com. google. guava: 11.0.2 '}

This test program is composed AssembleTestTask build. It is not in main AssembleTask dependency. It is not automatically called when testing is set.

Currently, there is only one Build TypeWill be tested. By default Debug Build TypeBut it can be reconfigured:

Android {... testBuildType "staging "}

As mentioned above, a connection device is required to run the check through the connectedCheck task. It depends on the task androidTest, so it will run androidTest. This task performs the following operations:

• Make sure that both the application and the test application are built (depending on assembleDebug and assembleTest)
• Install these two applications
• Run the test
• Uninstall these two applications.

If multiple devices are connected, all tests run on all connected devices in parallel. If one of the devices fails the test, the entire build fails.

All test results will be saved as XML files and the path is

Build/androidTest-results

(This is similar to the result of regular running of jUnit in build/text-result)

It can be configured in the following ways:
Configuration

Android {...
TestOptions {resultsDir = "$ project. buildDir/foo/results "}}

Android. testOptions. resultsDirThe value Project. file (String)
Test Android Libraries to test the Android Library project in the same way as to test the application project.

The only difference is that the entire Library (and its dependencies) is automatically added to the test application as the Library dependency. The result is that the test APK contains not only its own code, but also all the dependencies of the Test Library and Test Library.
The manifest of this Library is merged into the manifest of the test application (for example, any project that references this Library ).

Change the AndroidTest task to only install (and uninstall) the test APK (because there are no other APK to install)

Others are the same. When you run a unit test, Gradle outputs an HTML report to view the results.
The Android plug-in expands the HTML report on this basis, which aggregates the test results of all connected devices.
Reports for a single project the test report is automatically generated when the test is run. Its default location is

Build/reports/androidTests

It is similar to the position build/reports/tests of the jUnit report, or other reports normally located in build/reports/<plugin>.

This location can be customized in the following ways:

Android {...
TestOptions {reportDir = "$ project. buildDir/foo/report "}}

This report aggregates the tests that run on different devices.
Multi-project reports can be useful when running all tests in one or more projects with one or more applications and libraries.

To do this, you need to use another plug-in the same file. This plug-in can be configured as follows:

Buildscript {repositories {mavenCentral ()}
Dependencies {classpath 'com. android. tools. build: gradle: 0.5.6 '}}
Apply plugin: 'android-report'

This plug-in should be configured and used in the root project, that is Settings. gradleDirectory of the same level Build. gradle.

In the root folder, run the following command to run all the tests and aggregate the test reports:

Gradle deviceCheck mergeAndroidReports -- continue

Note: The -- continue option ensures that all tests for each subitem are run even if one of them fails. If this option is not added, the first failed test will interrupt the running of all tests, which may cause some projects to not execute their tests.
Lint supports starting from version 0.7.0. You can run lint for a specified variant or all variants. In this case, it generates a report, describes the specific variants that exist for each given problem.
You can configure the lint by adding one of the following lintOptions nodes. Generally, you only need to specify several of them. The following lists all available options.

Android {

LintOptions {

// If it is set to true, lint will not report the analysis progress quiet true // if it is true, when lint finds an error, stop gradle building abortOnError false // if it is true, only the error ignoreWarnings true is reported. // if it is true, the full or absolute path of the file is displayed when there is an error (true by default) // absolutePaths true // if it is true, all problems are checked, including non-checkAllWarnings true by default. // if it is true, all warnings are considered as error warningsAsErrors true // do not check the given question id disable 'typographyfractions', 'typographyquotes '// check the given question id enable 'rtlhardcoded', 'rtlcom Pat ', 'rtlenabled' // * Only checks the given question id check 'newapi ', and 'inlinedapi' // if it is true, the output of the error report does not include the source code line noLines true // if it is true, all the places where an error is located will be displayed without truncating the list, and so on. ShowAll true // reset the lint configuration (use the default severity and other settings ). LintConfig file ("default-lint.xml") // if true, generate a plain text Report of the problem (default: false) textReport true // configure the location where the write output result is written; it can be a file or "stdout" (standard output) textOutput 'stdout' // if it is true, an XML report is generated, to use xmlReport false For Jenkins and so on // The file used to write the report (if not specified, the default is the lint-results.xml) xmlOutput file ("lint-report.xml") // if true, generates an HTML report (including the explanation of the problem, the source code for the problem, and so on). htmlReport true // the path for writing the report, it is optional (the default is the lint-results.html under the build directory) htmlOutput file ("lint-report.html ")

// If it is set to true, all release builds will run lint with the severity Level of issus as fatal (severity = false ).

// In addition, if a fatal (fatal) problem is found, the build will be aborted (controlled by the abortOnError mentioned above)

CheckReleaseBuilds true

// Set the severity level (severity) of the given issue to fatal (which means they will be checked during the release build (even if the lint issue to be checked is not included in the Code) fatal 'newapi ', 'inlineapi' // set the severity level of a given problem to error 'wakelock ', 'textviewedits '// sets the severity level of a given problem to warning 'resourceascolor' // sets the severity level (severity) of the given problem to ignore (same as not checking this issue) ignore 'typographyquotes '}

}