教程教案成果

Tableof译GoalsofthenewBuildSystem（gradle构建系统的目标WhyGradle？（为什么使用BasicProject（基本项目Simplebuildfiles（简单的构建文件ProjectStructure（项目结构ConfiguringtheBuildTasks（构建任务GeneralTasks（通用任务Javaprojecttasks（Java项目的AndroidBasicBuildCustomization（基本的构建定制Manifestentries（Manifest属性BuildTypes（构建类型signingconfigurations（签名配置RunningProguard（运Dependencies，AndroidLibrariesandMulti-projectsetup（依赖关系，Android库和多项目设置Dependenciesonbinarypackages（依赖二进制包Localpackages（本地包Remoteartifacts（文件Multiprojectsetup（多项目设置Libraryprojects（库项目CreatingaLibraryProject（创建一个库项目DifferencesbetweenaProjectandaLibraryProject（普通项目和库项目之间的区别ReferencingaLibrary（一个库项目LibraryPublication（库项目发布BasicsandConfiguration（基本知识和配置Runningtests（运试TestingAndroidLibraries（测试Android库Testreports（测试报告Singleprojects（独立项目Multi-projectsreports（多项目报告Lintsupport（Lint支持BuildVariants（构建变种版本Productflavors（不同定制的产品BuildType+ProductFlavor=BuildVariant（构建类型+定制产品=构建变种版本ProductFlavorConfiguration（ProductFlavor的配置SourcesetsandDependencies（源组件和依赖关系BuildingandTasks（构建和任务Multi-flavorAdvancedBuildCustomization（高级构建定制Buildoptions（构建选项JavaCompilationoptions（Java编译选项aaptoptions（aapt选项dexoptions（dex选项Manipulationtasks（操作BuildTypeandProductFlavorpropertyreference（BuildType和ProductFlavor属性参考 patibility1.7（使用 版本 GradleAndroid插件用户指南翻GradlePluginUserGuide原文地 本指南的翻译内容均出自于CSDN的琴弦第七，本人只是对其做出微小修正，对照了英文原文归纳整理成markdown文本并生成gibook，方便大家阅读学习。翻译原文地址点此打开。推出了全新的AndroidStudio集成开发环境，其中Android项目的结构与Eclipse的Android项目结构有很大的区别，原AndroidStudio使用Gradle构建工具，Eclipse的ADT插件使用的是Ant构建工具。因为两个构建工具的区别，导致了Eclipse开发环境的开发者刚开始比较难适应AndroidStudio。如果要迁移到AndroidStudio，建议最好了解下Gradle构建工具。Gradle插件就是AndroidGradlePlugin。本文是 的AndroidGradlePlugin使用指南翻译，以方便我大开发者学习。如英语水平还不错的同学，建议直接查 原文，本人的理解和翻译难免有所疏漏采用知识共享署名-非商业性使用-相同方式共享4.0国际协议进行本文档适用于0.9版本的Gradleplugin。由于我们在1.0版本之前介绍Gradle是一个优秀的构建系统和构建工具，它允许通过插件创建自定义的构建逻辑们基于Gradle以下的一些特点而选择采用了SpecificLanguage(DSL语言)来描述和控制构建逻辑构建文件基于roovy，并且允许通过混合DSL元素和使用代码来控制DSL元素以控制自定义的构建逻辑。支持Maven或者vy的依赖管理。Gradle1.10Gradle1.11Gradle1.12，并使用0.11.1插件版本。SDKbuildtools要求版本19.0.0。一些新的特征可能需要更高版本。 下applyapplyplugin:jaa这里引入了radle的Java插件。这个插件提供了所有构建和测试Java应用程序所需要的东最简单的Android项目的buildgradle文件包含以下内容：{{}dependenciesclasspath}}applyplugin:'android'android{compileSdkVersionbuildToolsVersion}这里包括了Androidbuildfile的3buildscrip{...buildscrip{...注意：这里的配置只影响控制构建过程的代码，不影响项目源代码。项目本身需要自己的仓库和依赖关系，稍后接下来，跟前面提到的JavaPlugin一样添加

配置了所有android构建过程需要的参数。这里也是AndroidDSL的点默认情况下，只需要配置目标编译SDK版本和编译工具版本，即compileSdkVersion和buildToolsVersion属性。个complieSdkVersion属性相当于旧构建系统中perites文件中的

注意：你同样需要在相同路径下添加一个perties文件，并使用sdk.dir属性来设置SDK另外，你也可以通过设ANDROID_HOME环境变量，这两种方式没有什么不同，根据你自己的喜好选择其中一种设置。上面提到的基本的构建文件需要一个默认的文件夹结构。radle遵循约定优先于配置的概念，在可能的情况尽可能提供合理的默认配置参数。基本的项目开始于两个名为“sourcesets”的组件，即mainsourcecode和testcode。它们分别里面每一个存在的文件夹对应相应的源组对于Javaplugin和Androidplugin来说，它们的Java源代码和资源文件路径如但对于Androidplugin来说，它还拥有以下特有的文件和文件夹结构当默认的项目结构不适用的时候，你可能需要去配置它。根据radle文档，重新为Java项目配置souceSes可以使用以下方法：{{main{javasrcDirsrjaa'}resourcessrcDireoe}}}srcDir将会被添加到指定的已存在的源文件夹中（这在Gradle文档中没有提到，但是实际上确实会这样执替换默认的源代码文件夹，你可能想要使用能够传入一个路径数组srcDirs来替换单srcDir。以下是使用调用对象的另sourceSetssourceSetsmain.java.srcDirs=[srjaa]main.resources.srcDirs=[srresoures]}想要获取信息，可以参考Gradle文档中关于JavaPluign的部分AndroidPlugin使用的是类似的语法。但是由于它使用的是自己的sourceSets，这android对象中。以下是一个示例，它使用了旧项目结构中的main源码，并且将androidTestsourceSet组件重新到tests文件夹。{{mainjava.srcDirs=['src']resources.srcDirs=['src']aidl.srcDirs=['src']renderscript.srcDirs=['src']res.srcDirs=['res']assets.srcDirs=}}} 们需要将这些sourceSet组件重新 下注意：setRoot()方法将移动整个组件（包括它的子文件夹）到一个新的文件夹动srandroidest 下。以上这些是Android特有的，如果配置在添加一个插件到构建文件中将会自动创建一系列构建任务(buildtasks)去执行（注：gradle属于任务驱动型构建工具，它的建过程是基于Task的）。Javaplugin和Androidplugin都会创建以下实际上assemble 这三个task不做任何事情。它们只是一个Task标志，用来告诉androidplugin添加实际需这就允许你去调用相同的task，而不需要考虑当前是什么类型的项目，或者当前项目添加了什么plugin。例如，添加了findbugsplugin将会创建一个新的task并且

gradlegradlegradlegradletasks--注意：Gradle会自动监视一个task的所有输入和输出。两次执 task并且期间项目没有任何改动，gradle会使用UP-DAE通知所有ask。这意味着第二次build执行的时候不会请求任何ask执行。这允许ask之间互相依赖，而不会导致不需要的构建请求被执行。Javaplugin主要创建了两个task，依赖于maintask（一个标识性的

task自身直接或者间接依赖于其他taskclassestask将会被调用于编译java源码。它很少被调用，因为testtask依赖于它（类似于classestask）。通常情况下，你只需要调assemblecheck，不需要其他task。你可以在Gradle文档中查看javaplugin的全部task。

Androidplugin使用相同的约定以兼容其他插件，并且附加了自己的标识性task

这个task将会在一个指定的设备或者模拟器上执行检查，它们可以同时在所有连接的设备上执

通过APIs连接设备来执行检查，这是在CL服务器上使用的

task不依赖于deviceCheck 一个Android项目至少拥有两个输出：debugAPK（调试版APK)和releaseAPK（发布版APK）。每一个输出都拥它们都依赖于其它一些tasks以完成构建一个APK需要多个步骤。其中assembletask依赖于这两个task，所以 gradlegradle assembleReleasechecktask也拥有自己的依赖connectedUiAutomatorTest(目前还没有应用到最后，只要task能够被安装（那些要求签名的task），androidplugin就会为所有构建类型（debugreleasetest）安装Androidplugin提供了大量DSL用于直接从构建系统applicationId(有效的包名-- 查阅ApplicationId对比PackageName)packageNameforthetestapplicationInstrumentationtest{compileSdkVersionbuildToolsVersion{versionCodeversionNameminSdkVersionSdkVersion}}android元素中的defaultConfig元素中定义所有配置之前的AndroidPlugin版本使用packageName来配置manifest文件中的packageName属性。从0.11.0版本开始，你需要在在构建文件中定义的强大之处在于它是动态的。例如，可以从一个文件中或者其它自定义的逻辑代码中版本信息defdefcomputeVersionName()}{compileSdkVersionbuildToolsVersion{versionCodeminSdkVersion16SdkVersion}}注意：不要使用与在给定范围内的geer方法可能引起的方法名。例如，在deaulConig中调用geVersionName(将会自动调用deaulConiggeVesionName()方法，你自定义的geVersionName方法就被取代掉了。PropertyDefaultvalueinDSLDefaultvaluefrommanifestifvaluefrommanifestif valuefrommanifestifvaluefrommanifestifvaluefrommanifestifapplicationId+N/A(setN/A(setN/A(setN/A(setifif(android.defaultConfig.testInstrumentationRunner==null)//assignabetter}如果这个值一直保持null，那么在构建执行期间将会实际替换成第三列的默认值。但是在DSL元素中并没有包含这个默认值，所以，你无法查询到这个值。除非是真的需要，这是为了预防解析应用的manies文件。默认情况下，AndroidPlugin会自动给项目设置同时构建应用程序的debug和release两个版本之间的不同主要围绕着这些配置通过BuildType对象来配置。默认情况下，这两个实例都会被创建，分别debugrelease版Androidplugin允许像创建其他构建类型一样定制debug 实例。这需要在buildTypes的DSL容器中配置s{debugapplicationIdSuffix}jnidebug{packageNameSuffix".jnidebug"jnidebugBuildtrue}}} 创建了一个名为jnidebug的新构建类型，并且这个构建类debug构建类型的一个副本。继续配置jnidebug构建类型，允许使用JNI组件，并且也添加了不一样的包名后缀。

initWith()或者直接使用闭PropertyDefaultvaluesforDefaultvaluesforrelease/33N/A(setN/A(setN/A(setN/A(set除了以上属性之外，BuildType还会受项目源码和资源影响对于每一个BuildType都会自动创建一个匹配的sourceSet<ileae这意味着Buildype名称不能是main或者androides（因为这两个是由plugin制实现的），并且他们互相之间都必须是唯一的。跟其他sourceSet设置一样，BuildType的sourceset{oejieeoo(oojie}另外，每一个BuildType都会创建一个新的assemble任务assembleDebugassembleRelease两个Task在上面已经提到过，这里要讲这两个Task从哪里被创建。当debugrelease上面提到的build.gradle代码片段中也会实现aeleietask，并且assemble会像依赖于assembleDebug和assembleRelease一样依赖于aeleie。提示：你可以在终端下输入gradleaJ去运aeleietask。默认情况下，debug被配置成使用一个debugkeystory。debugkeystory使用了默认的和默认key及默认的keyBuildType(构建类型)会自动使 SigningConfig(签名配置) debug{storeFile}myConfigstoreFilefile("other.keystore")storePassword"android"keyAlias"androiddebugkey"keyPassword"android"}}{foodebuggabletruejniDebugBuildtruesigningConfig}}}以上代码片段修改debugkeystory的路径到项目的 下。在这个例子中，这将自动影响其他使用到debug构建类型的这里也创SingleConfig（签名配置）和一个使用这个新签BuildType（构建类型）注意：只有默认路径下的debugkeystory不存在时会被自动创建。更改debugkeystory的路径并不会自动在新路径下创建debugkeystory。如果创建一个新的不同名字的SignConfig，但是使用默认的debugkeystore路径来创建一个非默认的名字的SigningConing，那么还是会在默认路径下创建debugkeystory。换句话说，会不会自动创建是根据 自动创建出来的debugkeystore）。注意：如果你将这些文件添加到版本控制工具中，你可能不希望将直接写到这些文件中。下面StackOverflow链接提供从控制台或者环境变量中获取的方法：http:/ a-release-signed-apk-file-using-gradle我们以后还会在这个指南中添加的详细信息。从GradlePluginforProGuardversion4.10之后就开始支持ProGuard。ProGuard插件是自动添加进来的。如果Build getDefaultProguardFile('proguard-}}{flavor1}flavor2proguardFile'some-other-}}}发布版本将会使用它的BuildType中的规则文件，productflavor（定制的产品版本）将会使用对应flavor中的规则文这两个文件都在SDK的路径下。使用geDeaulProguardile()可以获取这些文件的完整路径。它们除了是否要进行优化之外，其它都是相同的。setup（依赖关系，Android库和多项目设置 dependenciesdependenciescompileil(liooja)}android} DSL是标准GradleAPI中的一部分，所以它不属 这 最终的APK赖时可能用到的其它一些配置选项mainapplication（主module）testapplication（测试module）。debugBuildType（debug类型的编译）。

releaseBuildType（发布类型的编译）因为没有可能去构建一个没有关联任何BuildType（构建类型）的APK，APK默认配置了两个或两个以上的编译配置：compile和<buildtype>Compile.创建一个新的BuildType将会自动创建一个基于它名字的新配置。这对于debug版本需要使用一个自定义库（为了反馈实例化的信息等）但发布版本不需要，或者它们依赖于同一个库的不同版本时会非常有用。{{}dependencies{}android}

注意：radle会遵循依赖关系的传递性。这意味着如果一个依赖本身依赖于其它东西，这些东来。++++我们可以定义3个项目。Grand将会按照以下名字它们每一个项目都拥有自己的build.gradle文件来自己如何构建。另外，在根 下还有一个setting.gradle文件用于所有项目。这些文件的结构如下：|+|++|+|includeinclude':app',':libraries:lib1',其 项目可能依赖于这些库，这是通过以下依赖配置的dependenciesdependenciescompileoje(iiei}在上面的多项目配置中，:libraries:lib1和:libraries:lib2可能是一个Java项目，并且

但是，如果你想要共享代码来AndroidAPI或者使用Android样式的资源，那么这些库就不能是通常的Java项目，而应buildscriptbuildscript{}dependenciesclasspath}}applyplugin:'android-library'android{compileSdkVersion}这里创建了一个使用API15编译SourceSet的库项目，并且依赖关系的配置方法与应用程序项目的配置方法一样，同样也支通项目和库项目之间的区别一个库项目的main输出是一个aar包（它代表Android的归档文件）。它组合了编译代码（例如ja包或者是本地的so文件）和资源（manies，es，asses）。一个库项目同样也可以独立于应用程序生成一个测试用的apk来测试。 其余的部分，库项目与应用程序项目一样。它们都拥有buildtype和productflavor，也可以生成多个aar记住大部分BuildType的配置不适用于库项目。但是你可以根据库项目是否被其它项目使用或者是否用来测试来使用自定义的sourceSetdependenciesdependenciescompilerojet(lirarieslib)compileoje(iiei}注意：如果你要多个库，那么排序将非常重要。这类似于旧构建系统里面的pojecproperies文件中的依赖排序。一般情况下一个库只会发布它的releaseVariant（变种）版本。这个版本将会被所有它的项目使用，而不管它们本身自androidandroiddefaultPublishConfig}注意这里的发布配置名称的是完整的Vaian版本名称。Relesae，debug只适用于项目中没有其它特性版本的时候使用。如果你想要使用其它Vaian版本取代默认的发布版本，你可以：androidandroiddefaultPublishConfig}将库项目的所有Variant版本都发布也是可能的。我们计划在一般的项目依赖项目（类似于上述所说的）情况下允许这种做法，但是由于Gradle的限制（我们也在努力修复这个问题）现在还认情况下没有启用发布所有Variant版本。可以通过以下启{publishNonDefault}理解发布多个Vaian版本意味着发布多个ar文件而不是一个ar文件包含所有Vaian版本是非常重要的。每一个ar包都包含一个单一的Vaian版本。发布一个变种版本意味着构建一个可用的ar文件作为radle项目的输出文件。无论是发布到一个maven仓库，还是其它项目需要创建一个这个库项目的依赖都可以使用到这个文件。compilecompileoje(iieidependenciesdependenciespileproject(path:':lib1',configuration:'flavor1Release')pileproject(path:':lib1',configuration:}重要：注意已发布的配置是一个完整的Variant版本，其中包括了buildtype，并且需要像以上一样被重要：当启用非默认发布，maven发布插件将会发布其它Vaian版本作为扩展包（按分类器分类）。这意味着不能真正的兼容发布到maven仓库。你应该另外发布一个单一的Vaian版本到仓库中，或者允许发布所有配置以支持跨项目依赖。

下。在试sourceSe中会构建一个使用Android测试框架，并且可以部署到设备上的测试apk来测试应用程序。这里面包含单元测试，集成测试，和后续U自动化测试。这个测试sourceSe不应该包含AndroidManiesxl文件，因为这个文件会自动生成。{defaultConfigtestPackageNametestInstrumentationRunner"android.test.InstrumentationTestRunner"testHandleProfilingtruetestFunctionalTest}}在测试应用程序的manies文件中，insrumenaion节点的Package属性值会自动使用测试应用的package名称设置，即使这个名称是通过deaultonig或者Buildype对象自定义的。这也是manies文件需要自动生成的一个原因。另外，这个测试sourceSet也可以拥有自己的依赖。默认情况下，应用程序和他的依赖会自动添加的测试应用的classpathdependenciesdependencies }

task来构建。assembleTest不依赖于main

目前只有一个BuildType被测试。默认情况下 BuildType，但是这也可以通过以下自定义配置androidandroidtestBuildType}正如前面提到的，标志性taskconnectedCheck要求接的设备来启动。这个过程依赖 确认应用和测试应用都被构建（依赖于assembleDebug和assembleest）。安装这两个应用。败_build/androidTest-_build/androidTest-androidandroidtestOptionsresultsDir=}}这里的android.testOptions.resultsDir将由Project.file(String)获得唯一的不同在于整个库（包括它的依赖）都是自动作为依赖库被添加到测试应用中。结果就是测试APK不单码，还包含了库项目自己和库的所有依赖。库的manies被组合到测试应用的manies中（作为一些项目这个库的壳）。当运行单元测试的时候，Gradle会输出一份HTML格式的报告以方便查看结Androidplugin也是基于此，并且扩展了这非常类似于JUnit的报告所在位置build/reports/tests，其它的报告通常位于build/reportsplugin>/androidandroidtestOptionsreportDir=ojiliooeot}}在一个配置了多个应用或者多个库项目的多项目里，当同时运行所有测试的时候，生成一个报告文件记录所有的测试非常有用的。为了实现这个目的，需要使用同一个依赖文件（译注：指的是使用androidgradle插件的依赖文件）中的另一个插件。可以{{}dependenciesclasspath}}applyplugin:'android- gradlegradledeviceCheckmergeAndroidReports--注意：这里的coninue选项将允许所有测试，即使子项目中的任何一个运行失败都不会停止。如果没有这个选项一个失败测试将会终止全部测试的运行，这可能导致一些项目没有执行过它们的测试。从070版本开始，你可以为项目中一个特定的Vaian（变种）版本运行lin，也可以为所有Vaian版本都运行lin。它将会生成一个报告描述哪一个Vaian版本中存在着问题。{lintOptions//settotruetoturnoff ysisprogressreportingbylintquiettrue//iftrue,stopthegradlebuildiferrorsarefoundabortOnErrorfalse//iftrue,onlyreporterrorsignoreWarningstrue//iftrue,emitfull/absolutepathstofileswitherrors(trueby//absolutePaths//iftrue,checkallissues,includingthosethatareoffbydefaultcheckAllWarningstrue//iftrue,treatallwarningsaserrorswarningsAsErrorstrue//turnoffcheckingthegivenissuedisable//turnonthegivenissueenable pat',//check*only*thegivenissueid'scheck'NewApi','InlinedApi'//iftrue,don'tincludesourcecodelinesintheerroroutputnoLinestrue//iftrue,showalllocationsforanerror,donottrunca ists,etc.showAlltrue//Fallbacklintconfiguration(defaultseverities,etc.)lintConfigfile("default-lint.xml")//iftrue,generateatextreportofissues(falsebydefault)textReporttrue//locationtowritetheoutput;canbeafileor'stdout'textOutput'stdout'//iftrue,generateanXMLreportforusebyforexampleJeixmlReportfalse//filetowritereportto(ifnotspecified,defaultstolint-results.xml)xmlOutputfile("lint-report.xml")//iftrue,generateanHTMLreport(withissueexplanations,sourcecode,etc)htmlReporttrue//optionalpathtoreport(defaultwillbelint-results.htmlinthebuilddir)htmlOutputfile("lint-report.html")//settotruetohaveallreleasebuildsrunlintonissueswith//andabortthebuild(controlledbyabortOnErrorabove)iffatalissuesarefoundcheckReleaseBuildstrue//Settheseverityofthegivenissuestofatal eanstheywill//checkedduringreleasebuilds(evenifthelint isnotincluded)fatal'NewApi','InlineApi'//Settheseverityofthegivenissuestoerrorerror'Wakelock','TextViewEdits'//Settheseverityofthegivenissuestowarningwarning'ResourceAsColor'//Settheseverityofthegivenissuestoignore(sameasdisablingthecheck)ignore'TypographyQuotes'}}同一个应用的不同版本。例如一个免费的版本和一个的专业版本同一个应用需要打包成不同的apk以发布PlayStore。点击此处查看详细信息这个目标就是要让在同一个项目里生成不同的APK成为可能，以取代以前需要使用一个库项目和两个及两个以上的应用项目分别生成不同APK的做法。一个productflavor定义了从项目中构建了一个应用的自定义版本。一个单一的项目可以同时定义多个不同的flavor来改这个新的设计概念是为了解决不同的版本之间的差异非常小的情况。虽然最项目终生成了多个定制的版本，但是它们本质都是同一个应用，那么这种做法可能是比使用库项目更好的实现方式。Productflavor需要 androidandroid{flavor1}flavor2}}}这里创建了两个flavor，名为flavor1flavor2注意：flavor名不能与已存在的BuildType或 +定制产品=构建变种版本正如前面章节所提到的，每一个BuildType都会生成一个新的APKProductFlavor同样也会做这些事情：项目的输出将会拼接所有可能的BuildType和ProductFlavor（如果有Flavor定义存在每一种组合（包含BuildType和ProductFlavor）就是一个BuildVariant（构建变种版本）例如，在上面的Flavor例子中与默认的debug和release两个BuildType将会生成4个BuildFlavor1-debugFlavor1-releaseFlavor2-debugFlavor2-release项目中如果没有定义flavor同样也会有BuildVariant，只是使用的是默认的flavordefault(默认)的flavor/config是没有名字的，所以生成的BuildVariant列表看起来就跟BuildType列表一样。androidandroid{minSdkVersionversionCode}{flavor1versionCode20}flavor2minSdkVersion14}}}注意Produclavor类型的ductlaors.*对象与android.deaultonig对象的类型是相同的。这意味着它们共享相同的属性。deaultonig为所有的lavor提供基本的配置，每一个lavor都可以重设这些配置的值。在上面的例子中，最终的配置结果将会是：**`packageName`:`minSdkVersion`:`versionCode`:*`packageName`:`minSdkVersion`:`versionCode`:通常情况下，BuildType的配置会覆盖其它的配置。例如，BuildTypepackageNameSuffix会被追加到ProductFlavor的packageName上面。也有一些情况是一些设置可以同时在BuildType和ProductFlavor中设置。在这种情况下，按照个别为主的原则

就这种属性的一个例子。signingConfig允许通过设置android.buildTypes.release.signingConfig来为所有包共享相同的SigningConfig。也可以通过设ductFlavors.*.signingConfig来为每一个release包指定它们自己的SigningConfig与BuildType类似，ProductFlavor也会通过它们自己的sourceSet提供代码和资源。位于位于这些sourceSet用于与android.sourceSets.main和BuildType的sourceSet来构建APK。所有的Manifest文件都会合并成一个Manifest文件。类似于BuildType，允许ProductFlavor可以拥有不同的的组件和限所有使用的资源（Androidres和assets）遵循的优先级为BuildType会覆盖ProductFlavor，最终覆盖每一个BuildVariant都会根据资源生成自己的R类（或者其它一些源代码）。Variant互相之间没有共享的最终，类似BuildType，ProductFlavor也可以有它们自己的依赖关系。例如，如果使用flavor来生成一个基于的应用版 pile} 位于这些sourceSet拥有比BuildType的sourceSet更高的优先级，并允许在Variant的层我们前面提到每一个BuildType会创建自己的assemble<name>task，但是BuildVariant是BuildType和ProductFlavor的当使用ProductFlavor的时候，将会创建的assemble-typetask。分别是assemble<VariantName>允许直接构建一个Variant版本，例如assembleFlavor1Debugassemble<BuildTypeName>允许构建指定BuildType的所有APKassembleDebug将会构建Flavor1Debugassemble<ProductFlavorName>允许构建指定flavor的所有APKassembleFlavor1将会构建Flavor1Debug另 souceSe用于定义所有lavor共用的测试，但是每一个lavor也可以有它自己特有的测试。正如前面提到的，每一个lavor都会创建自己的测试sourceSe：位于{}pile

每一个flavor也拥有它们自己的task来这行这些测试：androidTest<VariantName最终的HTML报告支持根据flavor合并生成。下面是和报告文件的路径，第一个是每一个flavor版本的结果，后面的build/androidTest-results/flavors/<FlavorName>build/reports/androidTests/flavors<FlavorName>在一些情况下，一个应用可能需要基于多个标准来创建多个版本。例如，Play中的multi-apk支持4个不同的过滤器。区分创建的不同APK的每一个过滤器要求能够使用的ProductFlavor。假个需要一个免费版本和一个的版本，并且需要在muli-apk支持中使用AB过滤器（译注：AB，应用二进制接口，优点是不需要改动应用的任何代码就能够将应用迁移到任何支持相同AB的平台上）。这个应用需要3个AB和两个特定应用版本，因此就需要生成6个APK（没有因计算不同Buildypes生成的Vaian版本）。然而，注意到在这个例子中，为三个AB构建的版本源代码都是相同，因此创建6个lavor来实现不是一个好办法。相反的，使用两个lavor维自动构建所有可能的Vaian组合。这个功能的实现就是使用FlavorGroups。每一个Group代表一个维度，并且flavor都被分配到一个指定的GroupandroidandroidflavorGroups"abi","version"productFlavors{freeappflavorGroup}x86flavorGroup}}} 数组按照先后排序定义了可能使用的group。每一个ProductFlavor都被分配到一个group上面的例子中将ProductFlavor分为两组（即两个维度），为别为abi维度[x86,arm,mips]和version维度[freeapp,paidapp]，再加上默认的BuildType有[debug,release]，这将会组合生成以下的Bui