Android App開發中Gradle構建過程的配置方法

在build文件中使用了Android或者Java插件之後就會自動創建一系列可以運行的任務。
Gradle中有如下一下默認約定的任務:
1. assemble
該任務包含了項目中的所有打包相關的任務，比如java項目中打的jar包，Android項目中打的apk
2. check
該任務包含了項目中所有驗證相關的任務，比如運行測試的任務
3. build
該任務包含了assemble和check
4. clean
該任務會清空項目的所有的輸出，刪除所有在assemble任務中打的包
assemble, check 和 build 任務實際上並不做任何事情，它們其實只是為插件提供了一個鉤子，真正的事情都是由插件來完成的。
這樣的話，開發人員就不需要關心我到底運行的是一個java項目還是一個Android項目，也不用關心我到底使用了哪些gradle插件，因為我都可以調用這些約定的任務來完成構建。
比如使用findbugs插件會創建一個新的任務，並且使得check任務依賴於這個新建的任務，這樣每次執行check任務的時候，都會執行這個新建的任務。
在命令行執行
  

gradle tasks 

 
</pre>會列出所有主要的任務如果想看到全部的任務和它們的依賴，可以運行：<pre name="code" class="java">gradle tasks --all 
注意：Gradle會自動檢查一個任務的輸入和輸出。比如連續兩次運行build任務的，Gradle會報告所有的任務都已經是最新剛運行過的了，不需要再次運行。這樣的話，任務之間就算是有相互依賴，也不會導致重復的執行。
Java項目常用的任務
Java plugin 主要創建了兩個任務：
1. jar
assemble任務會依賴jar任務，看名字就知道這是負責打jar包的任務。jar任務本身又會依賴很多其他的任務，比如classes任務，classes任務會編譯java代碼
2. test
check任務會依賴test任務，這個任務會運行所有的測試。測試代碼使用testClasses任務編譯，但是我們基本不用手動運行testClasses任務因為test任務已經添加了對它的依賴。
通常情況下，我們只要運行assemble和check任務就夠了。
想查看java插件提供的所有任務以及他們的依賴可以點這個[鏈接](http://gradle.org/docs/current/userguide/java_plugin.html)
Android項目常用的任務
和其他gradle插件一樣，Android插件也提供了一些默認的任務，比如assemble，check，build，clean，同時它也提供了一些自己特有的任務，比如：
1. connectedCheck
運行那些需要在真機或者模擬器上執行的檢查任務，這些任務會並行地在所有連接的設備上運行
2. deviceCheck
使用APIs連接遠程設備執行檢查.主要用於CI(持續集成)服務上.
上面兩個任務都會執行 assemble 和 check任務。新加這兩個任務是很有必要的，這樣可以保證我們可以運行那些不需要連接設備的檢查任務。
注意：build任務並不依賴於deviceCheck或者connectedCheck
一個Android項目通常至少會有兩種輸出：debug apk和release apk。對應的gradle中有兩個任務可以分別輸出不同的apk：

• assembleDebug
• assembleRelease

這兩個任務又會依賴其他的任務來構建一個apk。assemble任務依賴這兩個任務，調用assemble任務就會生成兩種apk。

小提示： Gradle支持在命令行使用camel風格的縮寫來代替任務的名字，比如：

gradle aR 

等同於

gradle assembleRelease 

只要沒有其他任務的縮寫也是'aR'
check相關的任務的依賴：

• check依賴lint
• connectedCheck依賴 connectedAndroidTest和connectedUiAutomatorTest (還沒有實現)
• deviceCheck依賴於那些實現了test擴展的插件所提供的任務

最後，Android gradle插件還提供了install和uninstall任務，用來安裝和卸載apk

自定義構建過程之配置manifest
Android Gradle插件提供了大量的DSL來自定義構建過程，下面就來講解如何在gradle中配置manifest。
DSL提供了配置以下Manifest條目的功能:

• minSdkVersion
• targetSdkVersion
• versionCode
• versionName
• applicationId (更加方便有效的包名 -- [參考](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename))
• 測試app的包名
• Instrumentation test runner

示例：

android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName "2.0" 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
} 

android元素中的defaultConfig元素就是我們用來配置Manifest的地方。早期版本的Android插件使用packageName來配置manifest中的packageName屬性，從0.11.0開始，使用applicationId來代替packageName。這樣可以消除應用的包名（其實就是應用的id）和java的包名之間的混淆。

更強大的是build文件中描述的配置可以是動態的，比如可以從文件或者自定義的邏輯中獲取版本名稱。

def computeVersionName() { 
  ... 
} 
 
 
android { 
  compileSdkVersion 19 
  buildToolsVersion "19.0.0" 
 
 
  defaultConfig { 
    versionCode 12 
    versionName computeVersionName() 
    minSdkVersion 16 
    targetSdkVersion 16 
  } 
} 

 注意：不要使用作用域中的getter方法名作為函數名，比如在defaultConfig{}作用域中調用getVersionName（）將會自動調用defaultConfig.getVersionName()，而不會調用自定義的方法。
如果某個屬性的值沒有使用DSL設置，這個屬性將會使用某些默認值，下表展示了默認值的處理過程。
屬性名    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) 
如果你想在build腳本中使用自定義的邏輯來查詢這些屬性，第二列中的值就很重要。比如，你可以編寫如下的代碼：

if (android.defaultConfig.testInstrumentationRunner == null) { 
  // assign a better default... 
} 

如果屬性的值仍然是null，那麼在構建的時候，就會使用第三列的默認值，但是DSL元素中並不包含這些默認值，因此你不能在程序中查詢這些值。這樣做的目的是僅在必要的時候（構建時）才會去解析manifest內容。