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 

 
会列出所有主要的任务如果想看到全部的任务和它们的依赖，可以运行：

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内容。