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

gradle tasks 

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

• assembleDebug
• assembleRelease

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

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

gradle aR 

等同于

gradle assembleRelease 

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

• check依賴lint
• connectedCheck依賴 connectedAndroidTest和connectedUiAutomatorTest (還沒有實現(xiàn))
• deviceCheck依賴于那些實現(xiàn)了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文件中描述的配置可以是動態(tài)的，比如可以從文件或者自定義的邏輯中獲取版本名稱。

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

 注意：不要使用作用域中的getter方法名作為函數(shù)名，比如在defaultConfig{}作用域中調(diào)用getVersionName（）將會自動調(diào)用defaultConfig.getVersionName()，而不會調(diào)用自定義的方法。
如果某個屬性的值沒有使用DSL設置，這個屬性將會使用某些默認值，下表展示了默認值的處理過程。
屬性名    DSL對象中的默認值   默認值

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

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