3.4 自定义构建

Android plugin 提供了大量的 DSL 能够让你直接基于构建系统定制很多事情。

3.4.1 Manifest选项

通过 DSL 可以配置 manifest 的如下选项：

  • minSdkVersion
  • targetSdkVersion
  • versionCode
  • versionName
  • applicationId (更有效的 packageName — 请看ApplicationId 与 PackageName获取更多信息)
  • Package Name for the test application
  • Instrumentation test runner

示例:

1. android {
2. compileSdkVersion 19
3. buildToolsVersion "19.0.0"

5. defaultConfig {
6. versionCode 12
7. versionName "2.0"
8. minSdkVersion 16
9. targetSdkVersion 16
10. }
11. }

android 元素里的 defaultConfig 负责定义所有的配置。

Android Plugin 以前的版本是使用 packageName 配置 manifest 的’packageName’属性。 从 0.11.0 开始，你应该在 build.gradle 里使用 applicationId 来配置 manifest 的’packageName’属性。 这是为了消除应用的 packageName（也就是ID）和 java 的 packages 之间的歧义。

通过build文件定义的强大之处在于可以动态的被配置。 比如，可以从一个文件读取版本名字，或者使用一些其他的自定义的逻辑：

1. def computeVersionName() {
2. ...
3. }

5. android {
6. compileSdkVersion 19
7. buildToolsVersion "19.0.0"

9. defaultConfig {
10. versionCode 12
11. versionName computeVersionName()
12. minSdkVersion 16
13. targetSdkVersion 16
14. }
15. }

注意： 不要使用在给定的范围内，和其他已经存在的 getters 方法冲突的方法名字。比如在 defaultConfig { ...} 中调用 getVersionName() 方法会自动的调用 defaultConfig.getVersionName() 方法，如果你也自定义一个这样的名字的方法，那么你的方法不会调用。

如果一个属性没有通过DSL设置，则会使用它们的默认值。这里有个表格说明是如何处理的。

属性铭 DSL对象的默认值 默认值
versionCode -1 如有有的话从 manifest 中读取
versionName null 如有有的话从 manifest 中读取
minSdkVersion -1 如有有的话从 manifest 中读取
targetSdkVersion -1 如有有的话从 manifest 中读取
applicationId null 如有有的话从 manifest 中读取
testApplicationId null applicationId + “.test”
testInstrumentationRunner null android.test.InstrumentationTestRunner
signingConfig null null
proguardFile N/A (只能设置) N/A (只能设置)
proguardFiles N/A (只能设置) N/A (只能设置)

如果你在构建脚本中使用自定义的逻辑获取这些属性的时候，那么第二列的值尤其重要。比如，你可能这样写：

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

如果值一直为 null，那么在构建的时候，它将会被从第三列中获取的实际的默认值替换，但是在DSL元素中又不包含这个默认值，所以你无法查询到它。 这是为了防止解析应用的 manifest 文件，除非真的需要。