Android構建系統由一個Gradle的Android插件組成。 Gradle是一個高級的構建工具集,它能夠管理依賴,並使你可以定義定製化的構建邏輯。Android Studio使用了一個Gradle包裝器來完整地集成Gradle的Android插件。Gradle的Android插件也能夠獨立於Android Studio而運行。這意味着你能夠用Android Studio構建你的Android apps,也能夠從你機器的命令行或沒有安裝Android Studio的機器上構建你的Android apps(好比持續集成服務器)。 html
不管你是使用命令行,遠程主機仍是Android Studio來構建一個項目,構建的輸出都相同。 android
你的項目的構建配置(build configuration)在build.gradle文件裏定義,它們都是使用Gradle語法和選項及Android插件的純文本文件,它們配置了你的構建的以下幾個方面: shell
Build variants。構建系統能夠爲相同的模塊,根據不一樣的產品及構建配置產生多個APKs。當你想要構建你的應用程序的不一樣版本時這頗有用,它使你不須要爲每一個版本建立一個不一樣的項目或模塊。 apache
依賴。構建系統管理項目依賴,並支持對本地文件系統及遠程倉庫的依賴。這使你能夠再也不不得不搜索,下載,複製你依賴的二進制包到你的項目。 服務器
Manifest entries。構建系統使你可以在build variant配置中指定manifest文件的某些元素的值。這些構建值會覆蓋manifest文件裏的已有值。若是你想要爲你的模塊產生多個APKs這頗有用,其中每一個apk文件具備一個不一樣的應用程序名稱,最小SDK版本,或目標SDK版本。當有多個manifests出現時,manifest設定以buildType和productFlavor,/main manifest,和library manifests的優先級進行合併。 app
簽名。構建系統使你可以在構建配置中指定簽名設定,它還能夠在構建過程當中簽名你的APKs。 maven
ProGuard。構建系統使你可以爲每一個build variant指定一個不一樣的ProGuard規則文件。構建系統能夠在構建過程當中運行ProGuard來混淆你的類。 函數
測試。對於大多數的模板,構建系統建立一個測試目錄,androidTest並由你的項目的測試代碼產生一個測試APK,於是你不須要建立一個單獨測試項目。構建系統還能在構建過程當中運行你的測試。 工具
Gradle構建文件使用了領域特定語言(Domain Specific Language,DSL)經過Groovy語法來描述和控制構建邏輯。Groovy是一個動態語言,你能夠用它定義定製的構建邏輯,及與Gradle的Android插件所提供的Android特有元素進行交互。 測試
Android Studio構建系統對於項目的結構及其它構建選項的預設行爲有一些假定。若是你的項目符合這些慣例,你的Gradle構建文件將很是簡單。當這些慣例中的一些不適用於你的項目時,構建系統的靈活性使你可以配置構建過程的幾乎每一個方面。好比,若是你須要替換你的模塊目錄裏的默認源碼文件夾,你能夠在模塊的構建文件(build file)中配置一個新的目錄結構。
Android Studio裏的一個project,表明最頂層的Android開發結構。Android Studio工程包含工程文件和一個或多個應用程序模塊。一個模塊是你app的一個組件,你能夠獨立地對它進行構建,測試或調試。模塊包含你的apps的源代碼和資源。Android Studio工程能夠包含多種模塊:
Android應用程序模塊包含應用程序(mobile,TV,Weat,Glass)代碼,它可能依賴於庫模塊(library modules),儘管許多Android apps只由一個應用程序模塊組成。構建系統會爲應用程序模塊產生APK包。
Android庫模塊包含可複用的Android特有代碼和資源。構建系統會爲庫模塊產生一個AAR(Android ARchive)包。
App引擎模塊包含App引擎集成的代碼和資源。
Java庫模塊包含可複用的代碼。構建系統會爲Java庫模塊產生一個JAR包。
Android Studio工程包含一個頂層的Gradle構建文件,它使你能夠爲工程裏的全部應用程序模塊添加共用的配置選項。每一個應用程序模塊又有它本身build.gradle文件,來進行那個模塊特有的構建設定。
默認狀況下,工程級的Gradle文件使用buildscript元素來定義Gradle倉庫(repositories)和依賴(dependencies)。這使得不一樣的工程可使用不一樣的Gradle版本。支持的倉庫包括JCenter,Maven Central,或Ivy。這個例子聲明構建腳本使用JCenter倉庫,及一個包含1.0.1版Gradle的Android插件的classpath dependency artifact。
buildscript { repositories { jcenter() } dependencies { classpath 'com.android.tools.build:gradle:1.0.1' // NOTE: Do not place your application dependencies here: they belong // in the individual module build.gradle files } } allprojects { repositories { jcenter() } }
注意:Android Studio工程的SDK位置由local.properties文件裏的sdk.dir設定設置,或經過ANDROID_HOME環境變量設置。
應用程序模塊Gradle構建文件使你可以配置模塊構建設定,這包括覆蓋src/main manifest設定,及設置定製的打包選項。
android settings
defaultConfig和productFlavors
buildTypes
dependencies
這個例子應用Android插件,使用默認的配置來覆蓋多個manifest屬性,建立兩個build types:release和debug,並聲明瞭一些依賴:
apply plugin: 'com.android.application' android { compileSdkVersion 20 buildToolsVersion "20.0.0" defaultConfig { applicationId "com.mycompany.myapplication" minSdkVersion 13 targetSdkVersion 20 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } debug { debuggable true } } } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:20.0.0' compile project(path: ':app2, configuration: 'android-endpoints') }
注意:你能夠爲屬性值注入定製的構建邏輯,屬性值由一個函數定義,而函數又會被屬性調用,好比:
def computeVersionName() { ... } android { defaultConfig { versionName computeVersionName() ... } }
Android Studio構建系統可以管理工程依賴,它支持模塊依賴,本地二進制依賴,和遠程二進制依賴。
模塊依賴
一個應用程序模塊能夠在它的構建文件中包含一個它所依賴的其它模塊的列表。當構建這個模塊的時候,構建系統會聚集幷包含這些須要的模塊。
本地依賴
若是一個模塊依賴於你本地文件系統中已有的二進制包,好比JAR文件,你能夠爲那個模塊在構建文件中聲明這種依賴。
遠程依賴
當你的某些依賴能夠在一個遠程倉庫中得到時,你就不須要下載它們並把它們複製到你的工程裏了。Android Studio構建系統支持倉庫的遠程依賴,好比Maven,和依賴管理器,好比Ivy。
許多流行的軟件庫和工具均可以在公共的Maven倉庫中得到。對於這些依賴,你只須要指定它們的Maven座標便可,Maven座標能夠惟一地標識一個遠程倉庫中的每個元素。構建系統中使用的Maven座標的格式爲group:name:version。好比16.0.1版的Google Guava庫的Maven座標爲com.google.guava:guava:16.0.1。
Maven Central Repository被普遍地用於分發多種庫和工具。
Android Studio構建系統定義了一個build tasks的分層集合:頂層的或祖先的tasks調用它依賴的tasks來處理它的集合構建輸出。頂層的build tasks有:
assemble
check
build
clean
Android插件提供了connectedCheck和deviceCheck tasks來在connected,emulated,和remote devices時執行檢查。能夠經過點擊右側的Gradle標籤查看Gradle tasks。
你能夠在Android Studio或在命令行中查看全部可用tasks的列表並調用其中的任何一個,正如Building and Running from Android Studio和Build the project from the command line中所描述的那樣。
Android Studio工程包含有Gradle包裝器,它由以下幾部分組成:
注意:你應該把全部這些文件都提交到你的源碼版本控制系統裏。
使用Gradle包裝器(而不是本地安裝的Gradle)能夠確保你可以老是運行local.properties文件中定義Gradle版本。要配置你的工程使用一個更新的Gradle版本,只須要修改屬性文件並指定一個新的版本便可。
Android Studio從你工程裏的Gradle包裝器目錄下讀取屬性文件,並在這個目錄運行包裝器,這樣你就能夠無障礙地同時工做於多個須要不一樣Gradle版本的工程上了。
注意:Android Studio不使用shell腳本,於是當你用IDE進行構建時,你對shell腳本作的任何修改都不會起做用。你應該轉經過Gradle構建文件來定製你的構建邏輯。
你能夠在開發機或其它沒有安裝Android Studio的機器的命令行中運行shell腳原本構建你的工程。
注意:當你建立一個工程時,請只使用來自於一個可靠來源的Gradle包裝器腳本和JAR文件,好比Android Studio產生的那些。
在構建系統中,你的app的每一個版本由一個build variant表示。Build variants是product flavors和build types的組合。Product flavors表示一個app的產品構建版本,好比免費版和付費版。Build types表明爲每一個app包產生的構建打包版本,好比debug和release。構建系統會爲每一個product flavors和build types的組合產生APKs。
默認狀況下,Android Studio定義了默認的配置設定,在build.gradle文件中的defaultConfig,及兩個build types (debug和release)。這將建立兩個build variants,debug和release,構建系統將會爲每一個variant產生一個APK。
在默認的build types debug和release存在的同時,添加兩個product flavors,demo和full將產生四個build variants,每一個都有它本身的定製配置:
按優先級從低到高的合併順序爲libraries/dependencies -> main src -> productFlavor -> buildType。
某些工程具備複雜的多維度的功能組合,但它們仍然表示相同的app。好比,除了有app的demo和full版本以外,某些遊戲可能包含特定於一個特別的CPU/ABI的二進制文件。構建系統的靈活性使得爲一個工程產生以下的這些build variants成爲可能:
這個工程將由兩個build types (debug和release)和二維的product flavors組成,二維中的一個維度是app type (demo或full),另外一個是CPU/ABI(x86, ARM, or MIPS)。
要構建你的app的每一個版本,構建系統將結合以下這些目錄裏的源碼和資源:
src/main/ - 主源碼目錄(全部variants共用的默認配置)
src/<buildType>/ - 源碼目錄
src/<productFlavor>/ - 源碼目錄
注意:build type和product flavor源碼目錄是可選的,於是Android Studio不會爲你建立這些目錄。你應該在給構建配置文件添加build type和product flavor時建立這些目錄。若是這些目錄不存在,則構建系統將不使用它們。
對於那些沒有定義任何flavors的工程,構建系統使用defaultConfig設定,主app目錄和默認的build type目錄。好比,要在工程中沒有product flavors的狀況下產生默認的debug和release build variants,構建系統使用:
對於那些定義了一系列product flavors的工程,構建系統則合併build type,product flavor和主源碼目錄。好比,要產生full-debug build variant,構建系統合併build type,product flavor和主源碼目錄:
對於那些使用了多個flavor維度的工程,針對每一個維度構建系統合併一個flavor源碼目錄。好比,要產生arm-demo-release build variant,構建系統合併:
這些目錄下的源代碼會被一塊兒用來爲一個build variant產生輸出。你能夠在那些不會被用在相同variant的不一樣目錄下包含具備相同名字的類。
構建系統也會把全部的manifests合併爲一個單獨的manifest,從而每一個build variant能夠在最終的manifest中定義不一樣的組件或權限。manifests合併的優先級從低到高排列爲libraries/dependencies -> main src -> productFlavor -> buildType。
構建系統合併全部源碼目錄下的全部資源。若是同一個build variant的不一樣文件夾中包含了具備相同名字的資源,則優先級順序以下:build type資源覆蓋product flavor的那些資源,product flavor資源覆蓋主源碼目錄下的資源,主源碼目錄下的資源覆蓋庫的資源。
注意:Build variants使你可以在你的app的不一樣版本間複用共用的activities,應用程序邏輯,和資源。
Done。
原文。