本文共 1761 字，大约阅读时间需要 5 分钟。
DSL提供了配置以下Manifest条目的功能:
minSdkVersion / targetSdkVersion / versionCode / versionName / applicationId / 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对象中的默认值 | 默认值 |
|---|---|---|
| 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 |
如果你想在build脚本中使用自定义的逻辑来查询这些属性，第二列中的值就很重要。比如，你可以编写如下的代码：
if (android.defaultConfig.testInstrumentationRunner == null) { // assign a better default... } 如果属性的值仍然是null，那么在构建的时候，就会使用第三列的默认值，但是DSL元素中并不包含这些默认值，因此你不能在程序中查询这些值。这样做的目的是仅在必要的时候（构建时）才会去解析manifest内容。