Android Gradle插件用户指南

Posted 2020-07-11 七色音阶

原文Gradle Plugin User Guide - Android Tools Project Site
samples see bottom of New Build System
参考Gradle For Android Training Course

1 简介

这篇文档是基于0.9版本的Gradle插件，1.0以前的版本由于不兼容，可能会有所不同

1.1 新的构建系统的目标

新构建系统的目标是：

• 使得代码和资源的重用更加简单
• 使得创建同一应用程序的不同版本更加容易，不管是多个apk版本还是同一版本的多种定制
• 使得配置，扩展和自定义构建更加容易
• 良好的IDE集成

1.2 为什么使用Gradle

Gradle是一个高级构建系统和构建工具，允许通过插件自定义构建逻辑

以下一些功能使得我们选择Gradle：

• 使用特定领域语言(DSL)来描述和控制构建逻辑
• 构建脚本基于Groovy语言，允许通过DSL混合元素声明和通过代码控制DSL元素，来产生自定义的构建逻辑
• 支持Maven和(或者)Ivy管理依赖
• 非常灵活。允许使用最佳实践，但也不强制自己的实现方式
• 插件能够提供自己的DSL和API供构建脚本使用
• 提供优秀的工具API以供IDE集成

2 环境要求

• Gradle 1.10或者1.11或者1.12，以及插件版本0.11.1
• SDK以及Buid Tools 19.0.0，某些功能可能需要更新的版本

3 基本项目

Gradle项目通过项目根目录下的 build.gradle 文件来描述构建过程

3.1 简单的构建文件

最简单的Java项目构建文件 build.gradle

apply plugin: ‘java‘

这个脚本应用了Gradle的Java插件。这个插件了提供构建和测试Java应用的所有功能

最简单的android项目的构建文件包含以下内容：

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath ‘com.android.tools.build:gradle:0.11.1‘
    }
}

apply plugin: ‘android‘

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"
}    

Note(译注): 最新的android插件声明
apply plugin: ‘com.android.application‘

在这个Android构建脚本里包含了三个主要内容：

buildscript { ... } 配置了驱动构建过程的代码。在这个案例中，声明了使用Maven仓库，以及一个Maven文件(artifact)的依赖路径。这个文件就是包含了Android Gradle插件的库，版本为0.11.1

然后，android插件被应用，像之前的Java插件一样

最后，android { ... } 配置了anroid构建过程需要的参数。这也是Adnroid DSL的入口。默认的情况下，只有编译目标SDK版本，和构建工具版本是必须的。在脚本中，对应的是compileSdkVersion和buildtoolsVersion属性。compileSdkVersion和旧编译系统中project.properties文件中的target属性对应。这个新属性compileSdkVersion可以是一个int值(API Level)或者一个和之前的target属性值一样的字符串

重点: 你应该只应用android插件，同时应用java插件会导致构建错误

注意: 你同样需要一个local.properties文件来指明SDK的路径，和build.gradle在同一路径下，在文件中使用sdk.dir属性指明。或者，你可以设置ANDROID_HOME环境变量。两者是一致的，你可以选择一种你喜欢的方式。

3.2 项目结构

前面的android构建脚本使用了默认的文件夹目录结构。Gradle遵循约定优于配置的原则，在可能的情况下提供了合理的默认配置参数。

基本的项目包含两个“source sets”组件。main source code和test code，位于以下的目录中：

src/main/
src/androidTest/

在这些目录中，都存在目录对应源码组件

不管是Java还是Android插件，源码目录和资源目录都如下 ：

java/
resources/

对于Android插件，还有特有的文件和目录

AndroidManifest.xml
res/
assets/
aidl/
rs/
jni/

Note: src/androidTest/AndroidManifest.xml 不是必须的，会自动被创建。

3.2.1 配置项目结构

当默认项目结构不合适的时候，可以配置项目目录。根据Gradle文档，可以通过下面的脚本重新配置Java项目的sourceSets：

sourceSets {
    main {
        java {
            srcDir ‘src/java‘
        }
        resources {
            srcDir ‘src/resources‘
        }
    }
}

Note: srcDir 会添加指定的目录到源文件目录列表中(这在Gradele文档中没有提及，但是实际上是这样的)。

为了替换默认的源文件目录列表，可以使用srcDirs来指定目录数组。这也是一种不同的使用方式：

sourceSets {
    main.java.srcDirs = [‘src/java‘]
    main.resources.srcDirs = [‘src/resources‘]
}

更多的信息，参考Gradle文档中的Java插件内容

Android插件使用相似的语法，但是由于使用是自己的sourceSets，相应的目录在(build.gradle文件中的)android对象中指定

下面是一个示例，它使用旧项目的源码结构，并且将androidTest sourceSet映射到tests目录

android {
    sourceSets {
        main {
            manifest.srcFile ‘AndroidManifest.xml‘

            java.srcDirs = [‘src‘]

            resources.srcDirs = [‘src‘]

            aidl.srcDirs = [‘src‘]
            renderscript.srcDirs = [‘src‘]

            res.srcDirs = [‘res‘]
            assets.srcDirs = [‘assets‘]
        }

        androidTest.setRoot(‘tests‘)
    }
}

Note: 由于旧的结构将所有的源文件 (java, aidl, renderscript, and java资源文件)放在一个目录里，我们需要映射这些sourceSet组件到src目录。

Note: setRoot() 方法将整个sourceSet(包含子目录)指向新的目录。比如上面，将src/androidTest/* 指向了 tests/*

以上是Android特有的，如果配置在Java sourceSets中就没有作用

‘migrated’ 示例(位于本页面底部)中展示了这部分内容

3.3 构建任务

3.3.1 通用任务

在build文件中应用一个插件将自动创建一系列构建任务。Java插件和Android插件都是这样。任务约定如下：

• assemble

组合项目输出

• check

执行所有检查

• build

执行assemble和check两个task的所有工作

• clean

清理项目输出

任务assemble, check 和 build 不会做任何实际的事情。他们只是锚点任务(anchor tasks)，插件依赖他们来添加实际执行实际操作的任务。

这样就不需要考虑项目是什么类型，使用的是什么插件，都可以执行同样的任务。
例如，使用findbugs插件，会创建新的任务，并让check依赖这个任务，使得check被调用时这个任务就会被调用。

在终端(命令行，gradle项目目录下)中运行下面的任务可以查询到高级别的任务：

gradle tasks

运行以下命令可以看到全部任务和任务依赖关系：

gradle tasks --all

Note: Gradle自动监视一个任务声明的输入输出文件。再次执行构建任务时，如果文件没有改变，Gradle会指明所有任务为UP-TO-DATE，意味着任务不需要执行。这样的话，任务可以正确地互相依赖，而不不会导致非必须的构建操作

3.3.2 Java项目的任务

Java插件主要创建两个任务，下面是这两个锚点任务的依赖关系

• assemble
  
  • jar
    这个任务创建输出
• check
  
  • test
    这个任务运行测试

jar任务直接或间接地依赖其他任务：例如classes任务将编译Java源码
testClasses任务用于编译测试的，但是这个任务很少被调用，因为test任务依赖于它(就像依赖classes任务一样)

通常来说，你只需要调用assemble或者check任务，而不需要调用其他任务。

你可以在Gradle Java插件文档看到Java插件的全部任务和它们的描述

3.3.3 Android任务

Android插件使用同样的约定来保持和其他插件的兼容，并且添加了额外的锚点任务：

• assemble
  这个任务组织项目的输出

• check
  这个项目运行所有检查

• connectedCheck
  运行检查需要一个已连接的设备或者模拟器。并在所有已连接的设备上异步运行。

• deviceCheck
  通过APIs连接远程设备并运行检查。这通常在CI服务器上运行。

• build
  运行assemble和check

• clean
  清理项目输出

新的锚点任务是必须的，以保证在不需要设备连接的情况下能运行常规检查。
需要注意的是，build任务并不依赖deviceCheck或者connectedCheck

一个Android项目至少有两个输出：debug APK 和 release APK。它们每一个都有自己的锚点任务来帮助它们完成独立的构建：

• assemble
  
  • assembleDebug
  • assembleRelease

它们都依赖其它任务来完成构建一个apk所需要的多个步骤。assemble任务依赖这两个任务，所以调用assemble会生成两个APK。

Tip: Gradle支持在命令行中使用camel形式的任务名缩写。
例如：
gradle aR和gradle assembleRelease是一样的，因为没有别的任务名有同样的缩写

锚点任务check也有自己的依赖：

• check
  
  • lint
• connectedCheck
  
  • connectedAndroidTest
  • connectedUiAutomatorTest (not implemented yet)
• deviceCheck
  
  • 依赖于当其它插件实现测试扩展点时所创建的任务。

最终，插件会为所有构建类型(debug, release, test)创建install/uninstall任务，如果输出文件可以安装的话(必须签名)。

3.4 基本的构建过程定制

Android插件提供了大量DSL来直接从构建系统中定制大多数事情。

3.4.1 Manifest属性

通过DSL，可以配置以下manifest属性：

• minSdkVersion
• targetSdkVersion
• versionCode
• versionName
• applicationId (实际的packageName – 前往 ApplicationId versus PackageName 查看更多)
• Package Name for the test application
• Instrumentation test runner

例如：

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        versionCode 12
        versionName "2.0"
        minSdkVersion 16
        targetSdkVersion 16
    }
}

配置项位于android元素中的defaultConfig元素中。

之前版本的Android Plugin使用packageName来配置manifest文件的packageName属性。从0.11.1版本开始，你应该在build.gradle文件使用applicationId来配置manifest文件的packageName属性。
这是为了消除Android应用的packageName(作为Android应用的ID)和java包名之间的疑义。

在构建文件中定义的强大之处在于它可以是动态的。
例如，可以从一个文件中读取版本名称，或者使用自定义的逻辑：

def computeVersionName() {
    ...
}

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        versionCode 12
        versionName computeVersionName()
        minSdkVersion 16
        targetSdkVersion 16
    }
}

Note: 函数名不要与指定范围内已经存在的getter方法名冲突。例如，在defaultConfig { ...}中调用getVersionName()会自动使用defaultConfig.getVersionName()，而不是你自定义的其它getVersionName()。

如果属性没有通过DSL设置，那么默认的属性值会被使用。下面是默认的属性值列表：

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 (android.defaultConfig.testInstrumentationRunner == null) {
    // assign a better default...
}

如果这个值是null，那么在构建过程中会被第三列的默认值替代，但是DSL元素不会包含这个默认值(第三列的值)，所以你查询不到这个值。这是为了防止解析应用的manifest文件，除非真的必要。

3.4.2 构建类型(Build Types)

默认情况下，Android插件会自动设置项目同时构建debug和release版本的应用程序。
这两个版本的不同之处主要在于能否在一个安全设备上调试程序，和APK如何签名。

debug版本使用一个自动创建的密钥/证书，并使用已知的name/password来签名(防止构建过程中出现请求提示)。release版本在构建过程中没有签名，需要稍后签名。

这些配置通过一个构建类型(BuildTpye)对象来设置。默认情况下，debug和release这两个构建类型都会被创建。

Android插件允许自定义这两个实例，也允许创建其它构建类型。这些都在buildTypes的DSL容器中配置：

android {
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }

        jnidebug.initWith(buildTypes.debug)
        jnidebug {
            packageNameSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

上面的代码片段完成来以下功能：

• 配置默认的debug构建类型：

  • 将包名设置成<app appliationId>.debug，以便在同一设备上同时安装debug和release版本

• 创建了一个新的名为jnidebug的构建类型，是debug构建类型的一个副本

• 配置jnidebug构建类型，允许调试JNI组件，并且添加一个不同的包名后缀

创建一个新的构建类型就像在buildTypes容器中使用一个新的元素一样简单，可以通过调用initWith()或者使用闭包来配置

以下是可能用到的属性和它们的默认值：

Property name	Default values for debug	Default values for release / other
debuggable	true	false
jniDebuggable	false	false
renderscriptDebuggable	false	false
renderscriptOptimLevel	3	3
applicationIdSuffix	null	null
versionNameSuffix	null	null
signingConfig	android.signingConfigs.debug	null
zipAlignEnabled	false	true
minifyEnabled	false	false
proguardFile	N/A (set only)	N/A (set only)
proguardFiles	N/A (set only)	N/A (set only)

除了以上这些属性，Build Types还可以通过源码和资源来影响构建过程。
每一个构建类型都会创建一个匹配的sourceSet，默认的路径为：

src/<buildtypename>/

这意味这新的构建类型的名字不能是main或者androidTest(这是插件强制要求的)，而构建类型的名称必须是唯一的。

像其它sourceSet一样，构建类型的sourceSet可以重新被定向：

android {
    sourceSets.jnidebug.setRoot(‘foo/jnidebug‘)
}

另外，每一个Build Type都会创建一个assemble<BuildTypeName>任务。

在前面，assembleDebug和assembleRelease已经提到过了，这就是它们的来源。当debug和release构建类型被预创建的时候，它们相关的任务就被自动创建了，比如assembleDebug和assembleRelease

上面的build.gradle片段同样会创建assembleJnidebug任务，assemble会像依赖assembleDebug和assembleRelease任务一样依赖assembleJnidebug。

Tip: 你可以在命令行下输入gradle aJ来运行assembleJnidebug任务。

可能用到的场景：

• 只有debug模式才需要的权限，而release模式不需要
• 自定义debug实现
• debug模式使用不同的资源(例如，资源取值与签名证书绑定)

BuildType的源码和资源通过以下方式使用：

• manifest文件合并到app的manifest文件中
• 源码作为另一个源码目录
• 资源叠加到main的资源中，取代已经存在的值

3.4.3 签名配置

对一个应用程序签名需要以下：

• 一个keystore
• 一个keystore密码
• 一个key的别名
• 一个key密码
• 存储类型

位置，别名，两个密码和存储类型一个组成一个签名配置(SigningConfig)

默认情况下，debug签名配置使用一个debug keystore，已知的密码和已知的别名以及别名密码。
debug keystore位于$HOME/.android/debug.keystore，如果没有的话会自动创建一个。

debug构建类型会自动使用debug SigningConfig。

可以创建其它签名配置或者自定义默认内建配置。通过signingConfigs DSL容器来配置

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore")
        }

        myConfig {
            storeFile file("other.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
    }

    buildTypes {
        foo {
            debuggable true
            jniDebuggable true
            signingConfig signingConfigs.myConfig
        }
    }
}

上面的片段修改debug keystore的位置到项目根目录下。这会影响任何使用它的构建类型，在这个案例中，受影响的是debug构建类型。

这里也创建了一个新的签名配置和一个使用这个新签名配置的行的构建类型。

Note: 只有默认路径下debug keystore不存在的时候会被自动创建。改变debug keystore的路径则不会在新的路径下自动创建debug keystore。创建一个名字不同的签名配置，但是使用默认的debug keystore路径，会自动创建debug keystore。也就是说，是否自动创建debug keystore，是由keystore的位置决定，而不是配置的名称。

Note: keystore的路径通常是项目根目录的相对路径，但是也可以使用绝对路径，尽管不推荐这样(debug keystore除外，因为它会自动被创建)。

**Note: 如果你要把这些文件添加到版本控制系统中，你可能不想把密码写在文件中。下面的Stack Overflow连接提供了从从控制台或者环境变量读取的方法。
http://stackoverflow.com/questions/18328730/how-to-create-a-release-signed-apk-file-using-gradle
我们以后会更新指南，提供更多的细节**

3.4.4 运行ProGuard

ProGuard从Gradle plugin for ProGuard 4.10开始支持的(since Gradle plugin 0.4)。如果构建类型的minifyEnabled属性被设置为true，那么Progruard插件会自动被添加进来，对应的任务也自动被创建。

Note: 从Gradle插件版本0.14.0开始BuildType.runProguard更改为minifyEnabled属性。具体请参考Release notes

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFile getDefaultProguardFile(‘proguard-android.txt‘)
        }
    }

    productFlavors {
        flavor1 {
        }
        flavor2 {
            proguardFile ‘some-other-rules.txt‘
        }
    }
}

Variant会使用所有声明的规则文件，包括声明在相应的Build Type和flavor中的。

SDK中有两个默认的规则文件：

• proguard-android.txt
• proguard-android-optimize.txt

它们位于sdk路径下，使用getDefaultProguardFile()可以获取文件的完整路径。它们除了是否要进行优化之外，其它都是相同的。

3.4.5 压缩资源文件

构建时可以自动移除没有被使用的资源文件。更多详细信息请查看文档资源文件压缩

4 依赖关系，Android库项目和多项目设置

Gradle项目可以依赖其它组件，这些组件可以是外部二进制包，或者其它Gradle项目。

4.1 依赖二进制包

4.1.1 本地包

为了配置一个外部库jar依赖，你需要在compile配置中添加一个依赖

dependencies {
    compile files(‘libs/foo.jar‘)
}

android {
    ...
}

Note: dependenciesDSL元素是标准Gradle API的一部分，并不属于android元素。

compile配置是用来编译main应用的。任何添加到编译路径中的东西都会被打包到最终的apk文件中。
下面是其它一些在添加依赖时可能用到的配置：

• compile: 主module
• androidTestCompile: 测试module
• debugCompile: debug构建类型的编译
• releaseCompile: release构建类型的编译

因为构建一个apk必然有一个相关的构建类型，所以apk通常至少有两个编译配置：compile和<buildtype>Compile
创建一个构建类型时会自动创建一个基于它名字的编译配置<buildtype>Compile

当你在debug版本里需要使用一个自定义库（例如记录crash信息），而release版本不需要，或者他们依赖同一个库的不同版本的时候，会非常有用。

也可以通过添加一个目录来依赖目录下的所有jar文件：
compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])

4.1.2 远程文件

Gradle支持从Maven或者Ivy仓库获取依赖文件。

首先，必须把仓库添加到列表中，其次，必须按照Maven或者Ivy的文件声明规范来声明依赖。

repositories {
    mavenCentral()
}


dependencies {
    compile ‘com.google.guava:guava:11.0.2‘
}

android {
    ...
}

Note: mavenCentral()是指定仓库URL的便捷方式。Gradle支持远程和本地仓库。
Note: Gradle遵循依赖关系的传递性。如果一个被依赖文件也依赖其它文件，那些被依赖的文件也会被拉取下来。

更多关于配置依赖的信息，请查看Gradle用户指南和DSL文档

4.2 多项目设置

Gradle项目可以通过多项目设置依赖其它gradle项目。

一个多项目设置通常把所有子项目作为子目录放在指定的项目根目录下。

例如，项目结构如下：

MyProject/
 + app/
 + libraries/
    + lib1/
    + lib2/

我们在这个结构中定义3个项目。Gradle将通过以下名字引用它们：

:app
:libraries:lib1
:libraries:lib2

每个项目都有自己的build.gradle文件，声明来它怎样构建。另外，在根目录下还有一个settings.gradle文件，声明了所有的子项目。
目录结构如下：

MyProject/
 | settings.gradle
 + app/
    | build.gradle
 + libraries/
    + lib1/
       | build.gradle
    + lib2/
       | build.gradle

settings.gradle文件的内容十分简单：

include ‘:app‘, ‘:libraries:lib1‘, ‘:libraries:lib2‘

指明哪个文件夹是一个实际的Gradle项目。

:app项目或许依赖其它库项目，那么依赖关系声明如下：

dependencies {
    compile project(‘:libraries:lib1‘)
}

更多关于多项目设置的信息在这里。

4.3 库项目

在上面的多项目设置中，:libraries:lib1和:libraries:lib2可能是Java项目，:appAndroid项目将会使用它们输出的jar文件。

然而，如果你想要共享使用了Android API或者Android资源文件的代码(在库项目中使用了Android API或Android资源文件)，这些库项目就不能是常规的Java项目，必须是Android库项目。

4.3.1 创建一个库项目

一个库项目和常规的Android项目很相似，只有很少的区别。

因为构建库项目和构建应用程序不一样，所以使用不同的插件。构建库项目的插件和构建应用程序的插件在内部共享大部分的代码，并且它们都是由com.android.tools.build.gradlejar库提供。

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath ‘com.android.tools.build:gradle:0.5.6‘
    }
}

apply plugin: ‘android-library‘

android {
    compileSdkVersion 15
}

这是一个使用API 15编译的库项目。SourceSets和依赖关系的处理跟应用程序项目中一样，而且定制方式也一样。

4.3.2 普通项目和库项目的区别

一个库项目的主要输出是一个.aar包（它代表Android的归档文件）。它包含编译好的源码（例如jar文件或者本地.so文件）以及资源文件（manifest, res, assets）。
一个库项目也可以生成一个测试apk来测试，而不依赖应用程序。

由于使用同样的锚点任务（assembleDebug, assembleRelease），所以在命令行中构建库项目和普通项目没有区别。

其余部分，库项目和应用程序项目一样。都有构建类型和product flavors，可以生成多个版本的aar。
要注意的是，多数Build Type配置不适用于库项目。然而，你可以定制sourceSet来改变所依赖库的内容，不论它是被普通项目使用还是被测试。

4.3.3 引用一个库项目

引用一个库项目和引用其它项目的方式一样：

dependencies {
    compile project(‘:libraries:lib1‘)
    compile project(‘:libraries:lib2‘)
}

Note: 如果你由多个库项目，那么顺序是很重要的。这和旧构建系统中的project.properties文件中的依赖顺序一样重要。

4.3.4 库项目发布

默认的情况下，库项目只会发布release变种版本(release variant)。这个版本会被所有引用了库项目的项目使用，不管它们自己构建的是什么版本。这是Gradle导致的限制，我们正努力消除这个限制。

可以如下控制哪个版本会被发布：

android {
    defaultPublishConfig "debug"
}

要注意的是，这个发布配置名称必须是完整的variant名称，release和debug这两个名称只有在没有flavor的时候才使用。如果想要在有flavor的时候改变默认的发布版本，你必须这样写：

android {
    defaultPublishConfig "flavor1Debug"
}

发布库项目的所有版本也是可能的。我们计划在普通的项目依赖项目的工程中允许这种做法，但是由于Gradle的限制，现在还不能这么做（我们也在努力修复这个问题）。

发布所有版本的功能默认没有开启。开启如下：

android {
    publishNonDefault true
}

必须认识到发布多个variant版本意味着发布多个aar文件，而不是在一个aar文件中包含了多个variant版本。每一个aar文件就是一个独立的variant。

发布一个variant版本意味着构建出了一个可用的aar文件，作为Gradle项目的输出文件。这个文件可以发布到maven仓库，或者在其他项目依赖该库项目时作为依赖目标。

Gradle有默认文件的概念。下面这个就使用了默认文件：

compile project(‘:libraries:lib2‘)

为了依赖其他的发布版本，你必须指定具体使用哪一个：

dependencies {
    flavor1Compile project(path: ‘:lib1‘, configuration: ‘flavor1Release‘)
    flavor2Compile project(path: ‘:lib1‘, configuration: ‘flavor2Release‘)
}

重要: 要注意已发布的配置是完整的variant版本，包含了构建类型，因此引用的时候也必须是完整的。

重要: 当开启了无默认版本发布，Maven发布插件会把这些额外的版本作为扩展包（按分类器）发布。这意味着并不是真正兼容地发布到maven仓库。你应该发布一个独立的vatiant到仓库，或者开启发布所有配置来支持跨项目依赖。

5 测试

构建一个测试应用已经内置在应用项目内。不需要再创建单独的测试项目。

5.1 单元测试

试验性的单元测试功能支持已经加入到1.1中，具体请看这个页面。本节其他部分讲述的是”instrumentation tests”

5.2 基础和配置

正如前面提到的，紧邻着main sourceSet 的就是 androidTest sourceSet，默认在src/androidTest/路径下。

从这个sourceSet 会构建出一个使用Android测试框架，并且可以部署到设备上的测试apk来测试应用程序。这里面可以包含单元测试，集成测试，和后续UI自动化测试。

测试应用的<instrumentation>节点是自动生成的，但是你也可以创建一个src/androidTest/AndroidManifest.xml ，并在这个manifest文件中添加其他组件。

下面是一些测试应用可以配置的值：

• testPackageName
• testInstrumentationRunner
• testHandleProfiling
• testFunctionalTest

正如前面所看到的，这些在defaultConfig对象中配置：

android {
    defaultConfig {
        testPackageName "com.test.foo"
        testInstrumentationRunner "android.test.InstrumentationTestRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

在测试应用程序的manifest文件中，instrumentation节点的targetPackage属性值会自动使用测试应用的package名称设置，即使这个名称是通过defaultConfig或者Build Type对象自定义的。这也是manifest文件需要自动生成的一个原因。

另外，这个测试sourceSet也可以拥有自己的依赖。
默认情况下，应用程序和他的依赖会自动添加的测试应用的classpath中，但是也可以通过以下来扩展：

dependencies {
    androidTestCompile ‘com.google.guava:guava:11.0.2‘
}

测试应用通过assembleTest任务来构建。assembleTest不