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

示例:

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

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

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

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

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

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

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

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

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

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