gradle

1.介紹

如果你正在查閱build.gradle文件的所有可選項，請點擊這里進行查閱：DSL參考

1.1新構(gòu)建系統(tǒng)的特性

gradle構(gòu)建系統(tǒng)具有如下的特點：

• 易于代碼和資源復(fù)用
• 易于創(chuàng)建應(yīng)用的版本，例如發(fā)布多apk以及應(yīng)用的不同渠道版本
• 構(gòu)建過程易于配置，擴展和優(yōu)化
• 良好的IDE整合

1.2為什么使用Gradle？

Gradle既是一個先進的構(gòu)建系統(tǒng)，也是一個允許通過插件創(chuàng)建自定義構(gòu)建邏輯的構(gòu)建工具集。以下是一些我們?yōu)槭裁催x擇Gradle的原因：

• 用于描述和操作構(gòu)建邏輯的，基于Groovy的特定領(lǐng)域語言(DSL)
• 基于Groovy的構(gòu)建文件，允許混合通過使用DSL的聲明式元素以及使用代碼去操作DSL元素來提供自定義邏輯。
• 通過Maven或者Ivy的內(nèi)置依賴管理
• 非常靈活。
• 插件能夠?qū)С鲎约旱腄SL以及自己的API，用于使用構(gòu)建文件
• 支持IDE整合的良好工具API

1.3要求

• Gradle 2.2
• SDK版本19.0.0及以上，一些特性可能會需要更新的版本

2.基礎(chǔ)項目搭建

一個Gradle項目在一個文件中描述了該項目的構(gòu)建情況，該文件被稱為build.gradle，位于項目的根目錄。(點擊這里查看構(gòu)建系統(tǒng)概述)

2.1簡單的構(gòu)建文件

大多數(shù)簡單的Android項目擁有如下的build.gradle文件:

buildscript {
    repositories { 
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.3.1'
    }
}
apply plugin: 'com.android.application'
android {
    compileSdkVersion 23
    buildToolsVersion "23.1.0"
}

在Android的構(gòu)建文件中，有以下三個主要區(qū)域：
buildscript{…}用于配置用于構(gòu)建的代碼。在上面的例子中，聲明使用jCenter庫，并且有一個依賴于Maven類路徑的Maven Artifact。該Artifact是包含包含Android構(gòu)建插件的1.3.1版本Gradle。

上例中的Artifact僅僅影響到構(gòu)建代碼的運行，并不作用于代碼項目。至于項目本身需要聲明自己的庫和依賴關(guān)系，該部分將會在下文介紹。

之后，該構(gòu)建文件應(yīng)用了com.android.application插件。該插件用于構(gòu)建Android應(yīng)用。
最后android{…}中配置了所有用于Android應(yīng)用構(gòu)建的參數(shù)。這里是Android特定領(lǐng)域語言(DSL)的入口點。默認(rèn)情況下，僅僅編譯目標(biāo)(compilation target)和構(gòu)建工具版本(version of the build-tool)是必備的。也就是上例中的compileSdkVersion屬性和buildtoolsVersion屬性。該編譯目標(biāo)和舊版本的project.properties文件中的target屬性是相同的。新版本中既可以指定一個整型(即API level)，也可以使用表示相同值的字符串對compileSdkVersion進行指定。

重點：你應(yīng)當(dāng)使用com.android.application插件，使用java插件會導(dǎo)致錯誤。
注意1：另外，你也需要一個local.properties文件，設(shè)置sdk.dir去配置本地的SDK路徑位置。
注意2：另外，你也可以設(shè)置名為ANDROID_HOME的環(huán)境變量。 這兩者并沒有什么區(qū)別，你可以選擇任意一種。例如：sdk.dir=/path/to/Android/Sdk

2.2項目結(jié)構(gòu)

上面例子的基本構(gòu)建文件預(yù)期了一個默認(rèn)的文件夾結(jié)構(gòu)。Gradle遵循“約定優(yōu)于配置”的概念，盡可能提供良好的默認(rèn)項值?；卷椖坑蓛蓚€被稱為代碼集(source sets)的部分構(gòu)成，一個是主要的源代碼，另一個是測試代碼。它們各自位于：

• src/main
• src/androidTest

在這些目錄里，每一個資源組件都有各自的子目錄。對于Java和Android插件，java源代碼和java資源的路徑位置為：

• java/
• resources/

對于Android插件而言，有如下特定的文件和目錄：

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

這意味著主資源集中的所有*.java文件位于src/main.java中，主清單文件(main manifest)位于src/main/AndroidManifest.xml。

注意：
src/androidTest/AndroidManifest.xml由于會自動創(chuàng)建，因此并不是必須手動編寫的。

2.2.1配置結(jié)構(gòu)

當(dāng)默認(rèn)的項目結(jié)構(gòu)并不完善時，可能需要進行配置。本部分只介紹Android項目結(jié)構(gòu)的配置，關(guān)于純java項目的項目結(jié)構(gòu)配置，請參閱：gradle documentation。
Android插件使用和純java項目相同的語法，但是由于其使用自己的資源集，項目的配置由android{...}代碼塊完成。例如，舊的項目結(jié)構(gòu)(Eclipse)中對主代碼和測試代碼進行映射：

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')
      }
}

注1： 因為舊的結(jié)構(gòu)中在同一個文件夾中放入所有的資源文件，我們需要對這些資源集重新進行映射,將java代碼，資源文件等等放入src文件夾。
注2： setRoot()移動整個資源集和其子文件夾到一個新的文件夾中，上例將src/androidTest/*移動到tests/* 中，當(dāng)然此處的語句androidTest.setRoot('tests')只是Android的特性，并不適用于Java的資源集。

2.3構(gòu)建的任務(wù)

2.3.1通用任務(wù)

在構(gòu)建文件中應(yīng)用插件會自動創(chuàng)建一系列構(gòu)建任務(wù)的集合。Java插件和Android插件都是如此。關(guān)于任務(wù)的約定如下：

• assemble 該任務(wù)用于組合項目的輸出
  • check 該任務(wù)用于運行所有的的檢測
  • build 該任務(wù)執(zhí)行assemble和check任務(wù)
  • clean該任務(wù)清除項目的輸出

任務(wù)assemble，check以及build并不真正做任何事。這些插件中的“祖先”任務(wù)用于添加在任務(wù)中真正執(zhí)行的任務(wù)。
這樣，不論當(dāng)前的任務(wù)類型是什么以及何種插件被應(yīng)用，都將會允許你使用執(zhí)行相同的任務(wù)。例如，findbugs插件將會創(chuàng)建一個一個新的任務(wù)，并通過check任務(wù)進行依賴，無論什么時候執(zhí)行調(diào)用該任務(wù)，都可以直接使用check任務(wù)。
在命令行中，你可以通過下面的命令得到高級別任務(wù)：
gradle tasks
查看所有依賴任務(wù)列表可以使用下面的命令：
gradle tasks —all

注意：gradle自動顯示任務(wù)已經(jīng)聲明任務(wù)的輸入和輸出情況。

當(dāng)你在沒有變更項目內(nèi)容的情況下再次運行構(gòu)建任務(wù)時，Gradle將會報告所有的任務(wù)已經(jīng)UP-TO-DATE，意味著沒有需要運行的任務(wù)。這樣會使得任務(wù)彼此正確的依賴，而不需要沒必要的構(gòu)建操作。

2.3.2Java項目任務(wù)

以下是由Java插件所創(chuàng)建的，依賴于祖先任務(wù)的最重要的兩個任務(wù)：

• assemble jar：創(chuàng)建輸出的任務(wù)
• check test:運行測試的任務(wù)

jar任務(wù)本身直接或間接依賴于其他任務(wù)：例如classes任務(wù)將會編譯Java代碼。測試代碼被任務(wù)testClasses所編譯，但是就像classes任務(wù)一樣，幾乎很少有人會去調(diào)用，因為執(zhí)行test任務(wù)即可。
總的來說，你可能應(yīng)當(dāng)僅僅調(diào)用assemble任務(wù)或者check任務(wù)并忽略其他的任務(wù)。你可以點擊這里查看Java插件所有的任務(wù)集合及其描述信息：Java插件的任務(wù)集合

2.3.3Android的任務(wù)

Android插件使用相同的概念來保持和其他插件之間的兼容性，并且，Android插件還添加了額外的祖先任務(wù)：

• assemble
• check
• connectedCheck 運行check任務(wù)需要一個連接的設(shè)備或者模擬器，在所有的連接設(shè)備中，該任務(wù)將并行執(zhí)行。
• deviceCheck 使用API去連接遠(yuǎn)程設(shè)備，用于CI服務(wù)器(持續(xù)集成服務(wù)器)。
• build
• clean

新的祖先任務(wù)是必備的，這是為了能夠在不需要連接設(shè)備的情況下進行規(guī)則檢查。請注意，build任務(wù)并不依賴deviceCheck任務(wù)或者connectedCheck任務(wù)。
一個Android的項目有至少兩個輸出文件：一個debug apk文件以及一個release apk文件。它們中的每一個都有其自己的祖先任務(wù)來優(yōu)化構(gòu)建：

• assemble
  • assembleDebug
  • assembleRelease

assembleDebug和assembleRelease兩者都依賴于其他的多步任務(wù)執(zhí)行來構(gòu)建app文件。assemble任務(wù)依賴于assembleDebug和assembleRelease，可調(diào)用assemble任務(wù)構(gòu)建上述兩種apk。

提示： gradle支持駱駝命名法縮寫的形式在命令行中為任務(wù)命名。例如：
gradle aR
和下面的命令相同：
gradle assembleRelease
除非有其他任務(wù)和’aR’重復(fù)。

check任務(wù)有自己的依賴項：

• check
  • lint
• connectedCheck
  • connectedAndroidTest
• deviceCheck
  • 這取決于當(dāng)任務(wù)創(chuàng)建時，其他插件什么時候?qū)崿F(xiàn)測試拓展點。

最后，插件創(chuàng)建了安裝了卸載所有構(gòu)建類型的任務(wù)（包括debug，release和test），只要能夠被安裝（需要簽名）。例如：

• installDebug
• installRelease
• uninstallAll
  • uninstallDebug
  • uninstallRelease
  • uninstallDebugAndroidTest

2.4構(gòu)建自定義基礎(chǔ)

Android插件提供了一個寬泛的領(lǐng)域定制語言（DSL）在構(gòu)建系統(tǒng)中對大多數(shù)內(nèi)容進行自定義。

2.4.1Manifest條目

通過DSL，能夠配置最重要的manifest條目，例如：

• minSdkVersion
• targetSdkVersion
• versionCode
• versionName
• applicationId 關(guān)于包名，詳情請點擊：應(yīng)用ID VS 包名
• testApplicationId (用于測試apk)
• testInstrumentationRunner

例如：

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"


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

關(guān)于完整的構(gòu)建屬性清單以及其默認(rèn)值，請查看Android插件特定領(lǐng)域語言參考。
把這些清單屬性放入構(gòu)建文件中的好處是，這些值可以動態(tài)獲取。例如，別人可以從文件中閱讀版本名稱或者使用自定義邏輯：

def computeVersionName() {
    //...
}
android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"
    defaultConfig {
        versionCode 12 
        versionName computeVersionName()
        minSdkVersion 16
        targetSdkVersion 23
    }
}

注意：不要使用當(dāng)前域中可能和getters沖突的文件名。例如defaultConfig{...}調(diào)用getVersionName()會自動使用defaultConfig.getVersion()而不是自定義的方法。

2.4.2構(gòu)建類型

默認(rèn)情況下，Android插件自動建立了debug版和release版應(yīng)用。二者最大的不同是在安全設(shè)備（非開發(fā)設(shè)備）上的調(diào)試能力，以及APK文件被簽名的詳情信息。debug版本是由已知用戶名/密碼（防止在構(gòu)建過程中的提示）所自動創(chuàng)建的key/證書所簽名。release版本在構(gòu)建過程中并不被簽名，這將會在后面發(fā)生。
這項配置通過一個叫做BuildType的對象完成。默認(rèn)情況下,有兩個實例被創(chuàng)建，分別是debug版和release版。Android插件運行自定義這兩個實例，就像其他構(gòu)建類型一樣。這是由buildTypes特定領(lǐng)域語言容器所完成的：

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


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

上述片斷實現(xiàn)了如下內(nèi)容：

• 配置默認(rèn)的debug構(gòu)建類型
  • 設(shè)置包為”應(yīng)用ID.debug”，使得應(yīng)用的debug版和release版都能在同一個設(shè)備上安裝。
• 創(chuàng)建了一個新的叫作jnidebug的構(gòu)建類型，并對其使用debug構(gòu)建類型進行復(fù)制。
• 繼續(xù)配置jnidebug，開啟JNI組件調(diào)試功能，并添加一個不同的包名后綴。

創(chuàng)建一個新的構(gòu)建類型就和使用buildTypes容器下的一個新元素一樣簡單，要么調(diào)用initWith()要么將其完全配置結(jié)束。關(guān)于構(gòu)建類型的完整屬性清單，請查閱：Android構(gòu)建類型參考
另外，關(guān)于修改構(gòu)建屬性，構(gòu)建類型可以用于添加指定的代碼和資源文件。對每一種構(gòu)建類型，新的相匹配資源集被創(chuàng)建，其默認(rèn)位置為”src/構(gòu)建類型名稱”，例如src/debug/java目錄能夠用于添加僅僅在debug APK文件中所編譯的代碼或資源文件。這意味著構(gòu)建類型的命名不能和main以及androidTest重復(fù)（，并且必須獨一無二（這是插件所限制的）。
就像其他任何的資源集一樣，構(gòu)建類型資源的位置能夠重新指定：

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

此外，對于每一種構(gòu)建類型，一個新的assemble構(gòu)建類型名稱任務(wù)被創(chuàng)建，例如assembleDebug。assembleDebug任務(wù)和assembleRelease任務(wù)在上文中已經(jīng)被提及，這也就是他們?yōu)槭裁磿嬖诘脑?。?dāng)debug構(gòu)建類型和release構(gòu)建類型預(yù)創(chuàng)建時，這些任務(wù)(assembleDebug和assembleRelease)也會被自動創(chuàng)建。根據(jù)這個規(guī)則，上述的build.gradle片段也將會生成一個叫做assembleJnidebug的任務(wù)，該任務(wù)的依賴關(guān)系也和assembleDebug以及assembleRelease一樣。

提示：請記得你能夠輸入aJ來運行assembleJnidebug任務(wù)。

可能的使用情況：

• 一些權(quán)限只在debug模式下開啟，在release模式下禁用
• 調(diào)試的自定義實現(xiàn)
• debug模式下的使用資源不同（例如當(dāng)一個資源值與資源證書相掛鉤時）
  不同構(gòu)建類型的代碼/資源被用于以下情況：
• Manifest清單被合并到app清單文件中
• 作為其他資源文件夾的代碼
• 資源文件被主資源文件覆蓋并替換現(xiàn)有的值

2.4.3簽名配置

對一個應(yīng)用的簽名需要以下內(nèi)容(關(guān)于APK文件簽名的詳細(xì)信息，請查閱簽名你的應(yīng)用)：

• keystore
• keystore密碼
• keystore別名
• key密碼
• 商店類型

位置，key名稱以及密碼和商店類型共同構(gòu)成簽名配置。默認(rèn)情況下，debug配置使用debug keystore，其帶有已知的密碼和默認(rèn)的key和key的密碼。debug的keystore位于$HOME/.android/debug.keystore，如果不存在會被創(chuàng)建。debug構(gòu)建類型被自動設(shè)成使用debug簽名配置。
創(chuàng)建其他配置信息或自定義默認(rèn)的內(nèi)置配置信息是可行的。這是通過signingConfigs特定領(lǐng)域語言容器完成的：

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

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


    buildTypes {
        foo {
            signingConfig signingConfigs.myConfig
        }
    }
}

上述片段改變了debug版本keystore文件的位置為項目的根目錄。這將會自動影響到任何構(gòu)建類型，任何構(gòu)建類型都能夠使用它。在上例中即為debug構(gòu)建類型。這也將會創(chuàng)建一個新的簽名配置，新的構(gòu)建類型(foot)便可以使用這個新的簽名配置。

注意1：只有debug keystore文件自動創(chuàng)建并位于默認(rèn)位置。改變debug keystore文件位置并不會按需創(chuàng)建。只有使用不同命名創(chuàng)建簽名配置并使用默認(rèn)的debug keystore位置的情況下才會自動創(chuàng)建。從另一方面來說，這是和keystore文件的位置掛鉤的，而不是和配置信息的命名相對應(yīng)的。
注意2：keystore文件的位置通常情況下和項目的根目錄相關(guān)，但是也能夠是絕對目錄，雖然這并不被推薦（除非是debug的，因為它會自動被創(chuàng)建）。
注意3：如果你把這些文件納入到版本控制系統(tǒng)中，你可能并不想要把密碼放在其中。這里介紹了從控制臺或環(huán)境變量中讀取值的方法。

3.依賴，Android庫以及多項目建立

3.1依賴二進制包

3.1.1本地包

要去配置一個依賴庫或者額外的jar庫，你需要在compile配置中添加一個依賴關(guān)系。下面的片段在libs文件夾中添加了所有jar文件的依賴關(guān)系：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}


android {
    //...
}

注意：dependencies特定領(lǐng)域語言元素是標(biāo)準(zhǔn)Gradle API中的一部分。在這里面的每一項都被加入到編譯類路徑中，并都在最終的APK文件中被打包進去。以下是可能的配置信息：

• compile 主應(yīng)用
• androidTestCompile 測試應(yīng)用
• debugCompile debug構(gòu)建類型
• releaseCompile release構(gòu)建類型

由于在構(gòu)建APK時并不可能沒有關(guān)聯(lián)的構(gòu)建類型，因此APK總是被配置至少兩個編譯配置信息：compile以及構(gòu)建類型Compile。創(chuàng)建一個新的構(gòu)建類型將會自動創(chuàng)建一個基于該構(gòu)建類型名稱的編譯配置。如果debug版本需要添加一個自定義的庫（如報告程序崩潰情況）時，或者不同構(gòu)建類型依賴于相同庫的不同版本時這將是非常有用的（點擊這里詳見不同版本的沖突是如何處理的）。

3.1.2遠(yuǎn)程依賴

Gradle支持從Maven和Ivy庫中拉取依賴(artifact)。首先，該倉庫必須被添加到列表中，其次依賴必須被聲明。

repositories {
     jcenter()
}


dependencies {
    compile 'com.google.guava:guava:18.0'
}


android {
    //...
}

注意1：jcenter()是指定倉庫的URL縮寫。Gradle同時支持遠(yuǎn)程和本地的倉庫。
注意2：Gradle遵循依賴的傳遞性。這意味著，如果如果一個依賴，依賴于其本身，這也會被拉取。

關(guān)于建立依賴的更多信息，請閱讀Gradle使用指南和DSL文檔

3.2多項目的搭建

Gradle項目也能夠通過多項目搭建依賴于其他Gradle項目。一個多項目的搭建通常為將所有項目作為已給項目根目錄的子目錄。例如，給出如下的結(jié)構(gòu)：
MyProject/

• app/
• libraries/
  • lib1/
  • lib2/
    我們能夠識別出三個項目。Gradle會用下述的命名進行參考：
    :app
    :libraries:lib1
    :libraries:lib2
    每一個項目擁有其自己的build.gradle文件，聲明了其如何得到其構(gòu)建。額外的，將會有一個被命名為setting.gradle的文件位于根目錄，用于聲明所有項目。一下給出了結(jié)構(gòu)：
    MyProject/
    | settings.gradle
• app/
  | build.gradle
• libraries/
  • lib1/
    | build.gradle
  • lib2/
    | build.gradle

setting.gradle的內(nèi)容非常簡單。它定義了哪個文件夾是一個Gradle項目：

include ':app', ':libraries:lib1', ':libraries:lib2'

:app項目很可能依賴于其他的項目作為庫，這是通過以下聲明實現(xiàn)的：

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

關(guān)于多項目搭建的更多信息，請點擊這里。

3.3庫項目

在上述的多項目搭建中:libraries:lib1和:libraries:lib2作為Java項目，:appAndroid項目將會使用這兩個項目的jar輸出。但是，如果你想要通過Android API或使用Android風(fēng)格的資源來共享代碼，這些庫就不能是常規(guī)的Java項目，它們必須是Android庫項目。

3.3.1創(chuàng)建一個庫項目

一個庫項目和一個常規(guī)的Android項目非常相似。因為構(gòu)建庫和構(gòu)建應(yīng)用是不同的，因此使用的插件也不同。本質(zhì)上來說，兩個插件大多數(shù)代碼都是相似的，并且都由相同的com.android.tools.build.gradlejar文件提供。

buildscript {
    repositories {
        jcenter()
    }


    dependencies {
        classpath 'com.android.tools.build:gradle:1.3.1'
    }
}


apply plugin: 'com.android.library'


android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"
}

這將會創(chuàng)建一個使用API 23進行編譯的庫項目。資源集，構(gòu)建類型以及依賴關(guān)系的使用都和應(yīng)用項目相同，并可以通過相同的方式自定義。

3.3.2項目和項目庫的區(qū)別

庫項目的主要輸出是一個.arr包（表示Android archive），是編譯代碼（就像jar文件或者原生的.so文件一樣）和資源文件（清單，res文件以及assets文件）的組合。一個庫項目也可以生成一個測試apk文件用于測試庫的獨立性。對此使用的祖先任務(wù)也是相同的(assembleDebug和assembleReleas)。因此用命令去構(gòu)建這樣一個項目并沒有什么區(qū)別。對于其他方面，庫項目表現(xiàn)得和應(yīng)用項目一樣。庫項目也擁有構(gòu)建類型和產(chǎn)品渠道（product flavors，見下文），并且能夠潛在地生成多個版本的aar文件。請注意，構(gòu)建類型的大多數(shù)配置并不能夠用于庫項目。但是你可以使用自定義資源集來改變庫的內(nèi)容，這取決于當(dāng)前庫是否被用于一個項目，或者用于被測試。

3.3.4引用一個庫

引用一個庫和二進制包被引用是一樣的：

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

注意：如果你有多個庫，那么引用的順序就變得很重要。這和舊的構(gòu)建系統(tǒng)中在project.properties文件中的依賴順序一樣重要。

3.3.5庫發(fā)布

默認(rèn)情況下，一個庫僅僅發(fā)布其release版本。該版本被用于所有項目對庫的引用，不論這些項目本身使用怎樣的的構(gòu)建類型，而這是一個我們將要取消的臨時限制。你可以控制要發(fā)布何種版本：

android {
    defaultPublishConfig "debug"
}

注意，發(fā)布的配置名參考于版本的命名。Release和Debug版僅僅適合沒有渠道的情況下。如果你想要使用渠道改變默認(rèn)的發(fā)布版本，你可以這樣寫：

android {
    defaultPublishConfig "flavor1Debug"
}

發(fā)布一個庫的所有版本是可能的。我們計劃允許使用一個標(biāo)準(zhǔn)的項目到項目的依賴，但是目前這是不可能的，這是因為Gradle中的一些限制（我們正在努力解決這些）。
發(fā)布所有版本在默認(rèn)情況下是不可以的。下面的片段展示了如何開啟這項功能：

android {
    publishNonDefault true
}

很重要的一點是，你需要意識到發(fā)布多版本的arr文件而不是包含多個版本的arr文件。每一個arr包包含單個版本。發(fā)布一個版本意味著使得這個arr文件和Gradle項目輸出的依賴一樣可用。這能夠被用于當(dāng)發(fā)布到maven庫時，或者當(dāng)另一個項目依賴于該庫時。
Gradle有一個默認(rèn)依賴的概念。這是當(dāng)我們這樣寫時：

dependencies {
    compile project(':libraries:lib2')
}

創(chuàng)建一個依賴于另一個發(fā)布類庫的類庫時，你需要指定使用哪一個：

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

重點1：請注意到已發(fā)布的配置是全版本的，包括所有的構(gòu)建類型，并且需要被引用。
重點2：當(dāng)開啟非默認(rèn)發(fā)布時，maven發(fā)布插件將會發(fā)布這些額外的版本作為額外的包（帶有classifier）。這意味著發(fā)布到maven庫并不能真正地兼容。你應(yīng)該發(fā)布一個單版本，或者開啟所有的配置用于發(fā)布內(nèi)部項目依賴。

4.測試

應(yīng)用項目中整合了測試應(yīng)用的構(gòu)建。因此不需要再有一個獨立的測試項目。

4.1單元測試

在1.1中所提到的單元測試支持，請點擊這里。本章節(jié)的剩下部分介紹了“工具測試(instrumentation tests)”，能夠運行在真機或者模擬機上，其要求是要構(gòu)建一個測試APK文件。

4.2基礎(chǔ)配置

如之前所提到的，main資源集后面就是androidTest資源集，默認(rèn)情況下位于src/androidTest，使用這個資源集使得測試APK被構(gòu)建并能夠安裝到設(shè)備中，從而可以使用Android測試框架來測試應(yīng)用，包括Android單元測試，instrumentation tests以及uiautomator tests。清單中的<instrumentation>節(jié)點是被生成的，但是你可以創(chuàng)建一個src/androidTest/AndroidManifest.xml文件來添加測試清單(manifest)的其他組件。
還有一些值能夠在instrumentation測試應(yīng)用中配置。（詳情請查閱DSL參考）

• testApplicationId
• testInstrumentationRunner
• testHandleProfiling
• testFunctionalTest

如前所述，上述信息被配置在defaultConfig對象：

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

測試應(yīng)用清單文件的instrumentation節(jié)點中targetPackage屬性的值自動化填充為測試應(yīng)用的包名。即使在defaultConfig中或者在構(gòu)建類型對象中自定義,該值并不會發(fā)生改變。這也就是清單文件被自動生成的部分原因。
另外，androidTest資源集能夠配置自己的依賴關(guān)系。默認(rèn)情況下，應(yīng)用和其自身的依賴被添加到測試app的類路徑中，但是可以使用下面的片段進行擴展：

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

測試app是由assembleAndroidTest任務(wù)構(gòu)建的。這并不是對主assemble任務(wù)的依賴，而是當(dāng)測試準(zhǔn)備運行時自動調(diào)用的。
當(dāng)前只有一個構(gòu)建類型能夠被測試。默認(rèn)情況下是debug構(gòu)建類型。但是可以進行如下配置：

android {
    //...
    testBuildType "staging"
}

4.3解決主apk和測試apk之間的沖突

當(dāng)instrumentation測試運行時，主APK和測試APK共享相同的類路徑。如果主APK和測試APK使用相同的庫（如Guava）的不同版本時，Gradle構(gòu)建會失敗。如果gradle并不捕獲這一點，你的應(yīng)用會在測試版和正常版表現(xiàn)地不同（包括任何會崩潰的情況）。
為了讓應(yīng)用構(gòu)建成功，請確保兩個APK都使用相同版本的庫。如果錯誤來自于間接依賴（在你自己的build.gradle中沒有聲明的庫），僅僅在需要的地方(compile或者androidTestCompile)添加最新的依賴即可。你也可以使用Gradle解決沖突機制。你可以通過運行以下代碼檢查依賴樹：./gradlew :app:dependencies和./gradlew :app:androidDependencies。

4.4運行測試

如前所述，check任務(wù)需要一個連接的設(shè)備，并通過祖先任務(wù)connnectedCheck啟動。這個任務(wù)會依賴connectedDebugAndroidTest。這個任務(wù)做了以下幾件事：

• 確保app和測試app被構(gòu)建(依賴于assembleDebug和assembleDebugAndroidTest)。
• 安裝兩款應(yīng)用
• 運行測試
• 卸載兩款應(yīng)用

如果有多個設(shè)備連接，所有的測試都會平行運行在所有連接的設(shè)備上。如果其中一個測試失敗，在任何設(shè)備中，構(gòu)建都將會失敗。

4.5測試Android庫

測試Android庫項目和測試Android應(yīng)用項目是完全相同的。唯一的區(qū)別在于，整個庫以及依賴作為測試app的一個庫被自動添加。結(jié)果是，測試APK不僅僅包括了自身的代碼，也包含了庫本身及其依賴。androidTest任務(wù)變成僅僅安裝(卸載)測試APK（因為沒有其他APK可供安裝）。

4.6測試報告

當(dāng)運行單元測試時，Gradle輸出一個HTML格式的報告可供輕松地查看結(jié)果。Android插件構(gòu)建并拓展HTML報告用于從所有連接設(shè)備中匯集。所有的測試結(jié)果以xml文件的形式存儲在build/reports/androidTests/中（和常規(guī)的jNnit存儲在build/reports/tests相似）。該路徑可配置如下：

android {
    //...
    testOptions {
        resultsDir = "${project.buildDir}/foo/results"
    }
}

android.testOptions.resultsDir的值請參考：Project.file(String)。

4.6.1多項目報告

在帶有多應(yīng)用和多庫的多項目的搭建中，當(dāng)同時運行所有測試時，可能生成一個所有測試的測試報告是很有用的。
為了做到這一點，可用一個不同的gradle插件：

buildscript {
    repositories {
        jcenter()
    }


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


apply plugin: 'android-reporting'

這應(yīng)該被用在根項目中，也就是setting.gradle旁邊的build.gradle。
之后，從根文件夾開，以下的命令將會運行所有的測試并匯集成報告：
gradle deviceCheck mergeAndroidReports --continue

注意：--continue選項確保了所有子目錄在內(nèi)的所有測試都能夠被運行，即使其中有失敗的情況。

4.7Lint支持

你可以在一個指定版本運行l(wèi)int檢查（如下），例如：./gradlew lintRelease或者全版本的lint檢查(./gradlew lint)，在這種情況下會產(chǎn)生一個描述指定版本的報告。你可以通過添加lintOption部分來配置lint（如下）。你應(yīng)該添加一些典型的部分：詳見。

android {
    lintOptions {
        // turn off checking the given issue id's
        disable 'TypographyFractions','TypographyQuotes'

        // turn on the given issue id's
        enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'

        // check *only* the given issue id's
        check 'NewApi', 'InlinedApi'
    }
}

5.構(gòu)建版本

新構(gòu)建系統(tǒng)的一個目標(biāo)就是能夠?qū)ν粋€應(yīng)用創(chuàng)建不同的版本。
主要使用情況有兩個：

1. 一個應(yīng)用的不同版本。例如，一個免費/demo版本和一個專業(yè)版本
2. 同一個應(yīng)用在Google Play商店打包分發(fā)多個詳見：http://developer./google/play/publishing/multiple-apks.html
3. 前兩者的組合

目標(biāo)是能夠在同一個項目中生成不同的應(yīng)用，而不是使用同一個庫的不同應(yīng)用項目。

5.1產(chǎn)品渠道

產(chǎn)品渠道(product flavor)定義了一個項目應(yīng)用構(gòu)建的自定義版本。單個的項目可以有不同的渠道，從而生成的應(yīng)用不同。
這個新的概念被設(shè)計用于幫助版本差異非常小的情況下。如果當(dāng)問到“這是否是同一個應(yīng)用？”時，如果是，那么通過庫項目去實現(xiàn)可能更適合一些。
產(chǎn)品渠道通過一個叫做productFlavors的特定領(lǐng)域容器聲明：

android {
    //....


    productFlavors {
        flavor1 {
            //...         
        }


        flavor2 {
            ...
        }
    }
}

上例中將會創(chuàng)建兩個渠道，分別是flavor1和flavor2

注意：渠道的名稱不能喝已經(jīng)存在的構(gòu)建類型名稱沖突，也不能使用androidTest和test資源集的名稱。

5.2構(gòu)建類型+產(chǎn)品渠道=構(gòu)建版本

正如我們前面所看到的，每一個構(gòu)建類型生成一個新的APK文件。產(chǎn)品渠道也是相同的：項目的輸出變成所有可能構(gòu)建類型和產(chǎn)品渠道的組合。每一個（構(gòu)建類型，產(chǎn)品渠道）組合被稱為構(gòu)建版本。例如，在默認(rèn)的debug和release構(gòu)建類型中，上面的例子可以生成四個構(gòu)建版本：

• Flavor1 - debug
• Flavor1 - release
• Flavor2 - debug
• Flavor2 - release

沒有渠道的項目依然擁有構(gòu)建版本，使用的是單個默認(rèn)的default渠道/配置.

5.3產(chǎn)品渠道配置

每一個渠道的完整配置如下：

android {
    //...


    defaultConfig {
        minSdkVersion 8
        versionCode 10
    }


    productFlavors {
        flavor1 {
            applicationId "com.example.flavor1"
            versionCode 20
         }

         flavor2 {
             applicationId "com.example.flavor2"
             minSdkVersion 14
         }
    }
}

注意到android.productFlavors.*對象是ProductFlavor，其類型和android.defaultConfig對象類型相同。這意味著它們共享相同的屬性。
defaultConfig為所有的渠道提供了基礎(chǔ)的配置，每一個種渠道能夠覆蓋它的任何值。在上述的例子中，配置信息以如下結(jié)尾：

• flavor1
  • applicationId: com.example.flavor1
  • minSdkVersion: 8
  • versionCode: 20
• flavor2
  • applicationId: com.example.flavor2
  • minSdkVersion: 14
  • versionCode: 10

通常情況下，構(gòu)建類型配置會覆蓋其他配置。例如，構(gòu)建類型的applicationIdSuffix追加在產(chǎn)品渠道的applicationId后面。有一些在構(gòu)建類型和產(chǎn)品渠道都能夠設(shè)置的情況。在這種情況下，例如signingConfig就是這種屬性。這使得所有發(fā)布包共享這些簽名配置。通過設(shè)置android.buildTypes.release.signingConfig或者對每一個包通過設(shè)置自己的android.productFlavors.*.signingConfig來分別使用簽名配置。

5.4資源集和依賴

和構(gòu)建類型相似，產(chǎn)品渠道也是通過自己的資源集來貢獻(xiàn)代碼。上述的例子創(chuàng)建了四個資源集：

• android.sourceSets.flavor1 位置為src/flavor1

• android.sourceSets.flavor2位置為src/flavor2/

• android.sourceSets.androidTestFlavor1位置為 src/androidTestFlavor1/

• android.sourceSets.androidTestFlavor2位置為 src/androidTestFlavor2/
  這些資源集通過構(gòu)建類型和android.sourceSets.main被用于構(gòu)建APK。下面的規(guī)則用于處理所有被用于構(gòu)建單個APK的情況：

• 所有的代碼（src/*/java)共同用于多文件夾來生成單個輸出。

• 清單被共同合并到單個的清單中。這允許產(chǎn)品渠道擁有不同的組件、權(quán)限，和構(gòu)建類型相似。

• 所有的資源遵循覆蓋的優(yōu)先級。構(gòu)建類型覆蓋產(chǎn)品渠道，產(chǎn)品渠道覆蓋main資源集。

• 每個構(gòu)建版本生成自己的R類。各個版本直接不存在共享。

最后，和構(gòu)建類型一樣，產(chǎn)品渠道可以擁有自己的依賴。例如，如果渠道用于生成基于廣告的app或者付費的app，每一個渠道擁有自己的廣告sdk依賴。

dependencies {
    flavor1Compile "..."
}

在這個例子中，文件src/flavor1/AndroidManifest.xml可能需要包含網(wǎng)絡(luò)權(quán)限
每個版本同樣也創(chuàng)建了額外的資源集：

• android.sourceSets.flavor1Debug位于src/flavor1Debug
• android.sourceSets.flavor1Release位于src/flavor1Release
• android.sourceSets.flavor2Debug位于src/flavor2Debug
• android.sourceSets.flavor2Release位于src/flavor2Release

他們比構(gòu)建類型擁有更高的優(yōu)先級，并且允許自定義版本等級。

5.5構(gòu)建和任務(wù)

我們之前看到的，每一種構(gòu)建類型創(chuàng)建自己的assmble名字任務(wù)，但是構(gòu)建版本是構(gòu)建類型和產(chǎn)品渠道的組合。
當(dāng)使用產(chǎn)品類型時，更多的任務(wù)會被創(chuàng)建，如：

1. assemble構(gòu)建版本名
2. assemble構(gòu)建類型名
3. assemble產(chǎn)品渠道名

第1項允許你直接構(gòu)建單個的版本，例如aseembleFlavor1Debug。

第2項允許你構(gòu)建所有已給構(gòu)建類型的apk文件。例如assembleDebug將會構(gòu)建flavor1Debug和flavor2Debug。

第3項允許你構(gòu)建給定渠道的所有APK文件。例如，assembleFlavor1將會構(gòu)建assembleFlavor1Debug和assembleFlavor1Release。

任務(wù)assemble會構(gòu)建有可能的版本。

5.6多渠道版本

在一些情況下，可能會想要基于多種條件下創(chuàng)建相同應(yīng)用的多個版本。
考慮一個游戲作為例子，該游戲有一個demo版本和一個付費版本并且想要使用多apk支持中的ABI過濾條件。3個ABI和2個版本需要生成6個APK文件（不考慮構(gòu)建類型）。
但是，支付版本的代碼對于相對應(yīng)的3個ABI版本是相同的，因此創(chuàng)建6個渠道并不是一個好方法。
取而代之的是，配置兩個渠道版本，所有的構(gòu)建版本應(yīng)該自動構(gòu)建可能的組合。
這個功能是通過渠道規(guī)格(flavor dimension)來實現(xiàn)的。渠道被設(shè)置到指定的規(guī)格：

android {
    //...


    flavorDimensions "abi", "version"


    productFlavors {
        freeapp {
            dimension "version"
            //...
        }

        paidapp {
            dimension "version"
            ...
        }


        arm {
            dimension "abi"
            ...
        }
        
        mips {
            dimension "abi"
            ...
        }

       x86 {
           dimension "abi"
            ...
        }
    }
}

android.flavorDimensions數(shù)組定義了可能的規(guī)格。每一個產(chǎn)品渠道指定一個規(guī)格。
從指定了規(guī)格的產(chǎn)品渠道(free app,paid app)以及構(gòu)建類型（debug，release），能夠創(chuàng)建如下的構(gòu)建版本：

• x86-freeapp-debug
• x86-freeapp-release
• arm-freeapp-debug
• arm-freeapp-release
• mips-freeapp-debug
• mips-freeapp-release
• x86-paidapp-debug
• x86-paidapp-release
• arm-paidapp-debug
• arm-paidapp-release
• mips-paidapp-debug
• mips-paidapp-release

規(guī)格的順序是通過android.flavorDimensions定義的，這一點非常重要。
每一個版本通過不同的產(chǎn)品渠道進行配置：

• android.defaultConfig
• abi規(guī)格
• 版本規(guī)格

規(guī)格的順序驅(qū)動了是哪個渠道去覆蓋哪個渠道，這對于渠道的哪個資源值去替代另一個渠道的資源值而言非常重要。
渠道規(guī)格通過高優(yōu)先級進行定義。在這種情況下：

abi>version>defaultConfig
多渠道項目也擁有額外的資源集，和構(gòu)建版本資源集相似但是不包括構(gòu)建類型：

• android.sourceSets.x86Freeapp位于src/x86Freeapp
• android.sourceSets.armPaidapp位于src/armPaidapp

這樣允許渠道組合級別的自定義。他們比基本的渠道資源集擁有更高的優(yōu)先級，但是優(yōu)先級低于構(gòu)建類型資源集。

5.7測試

多渠道項目測試和簡單的項目測試非常相似。
androidTest資源集用于所有渠道的通用測試，而每個渠道可以有自己的測試。
如上所提及的，每個渠道的資源集按照如下形式被創(chuàng)建：

• android.sourceSets.androidTestFlavor1位于src/androidTestFlavor1
• android.sourceSets.androidTestFlavor2位于src/androidTestFlavor2/
  相似地，它們可以有各自的依賴：

dependencies {
    androidTestFlavor1Compile "..."
}

運行測試可以通過祖先任務(wù)deviceCheck完成，或者通過主androidTest任務(wù)。
每一個渠道都有自己的測試任務(wù)：androidTest版本名，例如：

• androidTestFlavor1Debug
• androidTestFlavor2Debug

相似地，測試APK的構(gòu)建和卸載安裝按照每個版本進行：

• assembleFlavor1Test
• installFlavor1Debug
• installFlavor1Test
• uninstallFlavor1Debug

最后，HTML報告生成支持通過渠道的匯總。
測試結(jié)果和報告的位置如下所示，首先是渠道版，其次是匯總版：

• build/androidTest-results/flavors/渠道名
• build/androidTest-results/all/
• build/reports/androidTests/flavors/渠道名
• build/reports/androidTests/all/

或者可以自定義路徑，但這僅僅改變了文件夾的根目錄，但是仍然會對每個渠道創(chuàng)建子目錄并匯集報告結(jié)果。

5.8構(gòu)建配置

Android Studio生成一個叫作BuildConfig的類，包含了用于構(gòu)建一個特定版本的常量值。你可以指定這些常量值來改變不同版本，例如：

private void javaCode() {
    if (BuildConfig.FLAVOR.equals("paidapp")) {
        doIt();
    else {
        showOnlyInPaidAppDialog();
    }
}

以下是構(gòu)建配置中含有的值：

• boolean DEBUG – if the build is debuggable.
• int VERSION_CODE
• String VERSION_NAME
• String APPLICATION_ID
• String BUILD_TYPE - 構(gòu)建類型的名字，例如”release”
• String FLAVOR – 渠道名稱，例如”paid app”

如果項目使用渠道規(guī)格，將會生成額外的規(guī)格。使用上面的例子，會有如下的構(gòu)建配置示例：

• String FLAVOR = "armFreeapp"
• String FLAVOR_abi = "arm"
• String FLAVOR_version = "free app"

5.9過濾版本

當(dāng)你添加規(guī)格和渠道時，你應(yīng)該停止使用沒有意義的版本。例如你可能為了更快的測試，會定義一個使用你的Web API的渠道，以及一個使用硬編碼的假數(shù)據(jù)。第二個渠道僅僅在開發(fā)的時候有用，但是在發(fā)布版本的構(gòu)建時卻沒有用處。你可以刪除這個版本，改成使用variantFilter，例如：

android {
    productFlavors {
        realData
        fakeData
    }

    variantFilter { variant ->
        def names = variant.flavors*.name

        if (names.contains("fakeData") && variant.buildType.name == "release") {
            variant.ignore = true
        }
    }
}

在上面的配置中，你的項目只有三個版本：

• realDataDebug
• realDataRelease
• fakeDataDebug

6.高級構(gòu)建自定義

6.1運行混淆

混淆插件在Android插件中被自動使用，如果構(gòu)建類型通過minifyEnabled屬性開啟了混淆，那么任務(wù)會被自動創(chuàng)建。

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

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

    }
}

版本使用所有在這個構(gòu)建類型以及產(chǎn)品渠道中聲明的規(guī)則文件。
有兩個默認(rèn)規(guī)則文件：

• proguard-android.txt
• proguard-android-potimize.txt

這些文件位于SDK中。使用getDefaultProguardFile()會返回文件的全路徑。這些文件是相同的，除非開啟了優(yōu)化。

6.2縮減資源

你可以在構(gòu)建時自動移除所有未使用的資源。關(guān)于更多信息，請查閱資源縮減文檔。

6.3操作任務(wù)

基本的Java項目擁有有限的任務(wù)集共同創(chuàng)建輸出。
classes是編譯java源代碼的任務(wù)之一，縮寫為：project.tasks.classes。
在Android項目中有一些復(fù)雜。這是因為可能有大量相同的任務(wù)，并且它們的名字基于產(chǎn)品渠道和構(gòu)建類型命名。
為了去解決這一點，android對象有以下兩個屬性：

• applicationVariants(只用于app插件)
• libraryVariants(只用于庫插件)
• testVariants(同時適用于app和庫插件)

三者分別返回ApplicationVariant，LibraryVariant，TestVariant的領(lǐng)域?qū)ο蠹?/a>。

android.applicationVariants.all { variant ->
   ....
}

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_6
        targetCompatibility JavaVersion.VERSION_1_6
    }
}