(四) Basic Build Customization（基本的构建定制 ：签名，构建，混淆）

Manifest entries （Manifest属性）

通过SDL可以配置一下manifest选项：

• minSdkVersion
• targetSdkVersion
• versionName
• applicationId (有效的包名 -- 更多详情请查阅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包名所引起的混乱。

在构建文件中定义的强大之处在于它是动态的。 例如，可以从一个文件中或者其它自定义的逻辑代码中读取版本信息：

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

注意：不要使用与在给定范围内的getter方法可能引起冲突的方法名。例如，在defaultConfig{...}中调用getVersionName()将会自动调用defaultConfig.getVersionName()方法，你自定义的getVersionName()方法就被取代掉了。

如果一个属性没有使用DSL进行设置，一些默认的属性值将会被使用。以下表格是可能使用到的值：

Property NameDefault value in DSL objectDefault valueversionCode-1value from manifest if presentversionNamenullvalue from manifest if presentminSdkVersion-1value from manifest if presenttargetSdkVersion-1value from manifest if presentapplicationIdnullvalue from manifest if presenttestApplicationIdnullapplicationId + “.test”testInstrumentationRunnernullandroid.test.InstrumentationTestRunnersigningConfignullnullproguardFileN/A (set only)N/A (set only)proguardFilesN/A (set only)N/A (set only)

如果你在构建脚本中使用自定义代码逻辑请求这些属性，那么第二列的值将非常重要。例如，你可能会写：

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

如果这个值一直保持null，那么在构建执行期间将会实际替换成第三列的默认值。但是在DSL元素中并没有包含这个默认值，所以，你无法查询到这个值。 除非是真的需要，这是为了预防解析应用的manifest文件。

Build Types（构建类型）

默认情况下，Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试，以及APK如何签名。

Debug版本采用使用通用的name/password键值对自动创建的数字证书进行签名，以防止构建过程中出现请求信息。Release版本在构建过程中没有签名，需要稍后再签名。

这些配置通过一个BuildType对象来配置。默认情况下，这两个实例都会被创建，分别是一个debug版本和一个release版本。

Android plugin允许像创建其他构建类型一样定制debug和release实例。这需要在buildTypes的DSL容器中配置：

android {    buildTypes {        debug {            applicationIdSuffix ".debug"        }        jnidebug.initWith(buildTypes.debug)        jnidebug {            packageNameSuffix ".jnidebug"            jnidebugBuild true        }    }}

以上代码片段实现了以下功能：

• 配置默认的debug构建类型
  • 将debug版本的包名设置为.debug以便能够同时在一台设备上安装debug和release版本的apk。
• 创建了一个名为jnidebug的新构建类型，并且这个构建类型是debug构建类型的一个副本。
• 继续配置jnidebug构建类型，允许使用JNI组件，并且也添加了不一样的包名后缀。

创建一个新的构建类型就是简单的在buildType标签下添加一个新的元素，并且可以使用initWith()或者直接使用闭包来配置它。

以下是一些可能使用到的属性和默认值：

Property nameDefault values for debugDefault values for release / otherdebuggabletruefalsejniDebugBuildfalsefalserenderscriptDebugBuildfalsefalserenderscriptOptimLevel33applicationIdSuffixnullnullversionNameSuffixnullnullsigningConfigandroid.signingConfigs.debugnullzipAlignfalsetruerunProguardfalsefalseproguardFileN/A (set only)N/A (set only)proguardFilesN/A (set only)N/A (set only)

除了以上属性之外，Build Type还会受项目源码和资源影响： 对于每一个Build Type都会自动创建一个匹配的sourceSet。默认的路径为：

src/<buildtypename>/

这意味着BuildType名称不能是main或者androidTest（因为这两个是由plugin强制实现的），并且他们互相之间都必须是唯一的。

跟其他sourceSet设置一样，Build Type的source set路径可以重新被定向：

android {    sourceSets.jnidebug.setRoot('foo/jnidebug')}

另外，每一个Build Type都会创建一个新的assemble任务。

assembleDebug和assembleRelease两个Task在上面已经提到过，这里要讲这两个Task从哪里被创建。当debug和release构建类型被预创建的时候，它们的tasks就会自动创建对应的这个两个Task。

上面提到的build.gradle代码片段中也会实现assembleJnidebug task，并且assemble会像依赖于assembleDebug和assembleRelease一样依赖于assembleJnidebug。

提示：你可以在终端下输入gradle aJ去运行assembleJnidebug task。

可能会使用到的情况：

• release模式不需要，只有debug模式下才使用到的权限
• 自定义的debug实现
• 为debug模式使用不同的资源（例如当资源的值由绑定的证书决定）

BuildType的代码和资源通过以下方式被使用：

• manifest将被混合进app的manifest
• 代码行为只是另一个资源文件夹
• 资源将叠加到main的资源中，并替换已存在的资源。

signing configurations（签名配置）

对一个应用程序签名需要以下：

• 一个Keystory
• 一个keystory密码
• 一个key的别名
• 一个key的密码
• 存储类型

位置，键名，两个密码，还有存储类型一起形成了签名配置。

默认情况下，debug被配置成使用一个debug keystory。 debug keystory使用了默认的密码和默认key及默认的key密码。 debug keystory的位置在$HOME/.android/debug.keystroe，如果对应位置不存在这个文件将会自动创建一个。

debug Build Type(构建类型) 会自动使用debug SigningConfig (签名配置)。

可以创建其他配置或者自定义内建的默认配置。通过signingConfigs这个DSL容器来配置：

android {    signingConfigs {        debug {            storeFile file("debug.keystore")        }        myConfig {            storeFile file("other.keystore")            storePassword "android"            keyAlias "androiddebugkey"            keyPassword "android"        }    }    buildTypes {        foo {            debuggable true            jniDebugBuild true            signingConfig signingConfigs.myConfig        }    }}

以上代码片段修改debug keystory的路径到项目的根目录下。在这个例子中，这将自动影响其他使用到debug构建类型的构建类型。

这里也创建了一个新的Single Config（签名配置）和一个使用这个新签名配置的新的Build Type（构建类型）。

---

注意：只有默认路径下的debug keystory不存在时会被自动创建。更改debug keystory的路径并不会自动在新路径下创建debug keystory。如果创建一个新的不同名字的SignConfig，但是使用默认的debug keystore路径来创建一个非默认的名字的SigningConing，那么还是会在默认路径下创建debug keystory。换句话说，会不会自动创建是根据keystory的路径来判断，而不是配置的名称。

---

注意：虽然经常使用项目根目录的相对路径作为keystore的路径，但是也可以使用绝对路径，尽管这并不推荐（除了自动创建出来的debug keystore）。

Running Proguard（运行 Proguard）

从Gradle Plugin for ProGuard version 4.10之后就开始支持ProGuard。ProGuard插件是自动添加进来的。如果Build Type的runProguard属性被设置为true，对应的task将会自动创建。

android {    buildTypes {        release {            runProguard true            proguardFile getDefaultProguardFile('proguard-android.txt')        }    }    productFlavors {        flavor1 {        }        flavor2 {            proguardFile 'some-other-rules.txt'        }    }}

发布版本将会使用它的Build Type中声明的规则文件，product flavor（定制的产品版本）将会使用对应flavor中声明的规则文件。

这里有两个默认的规则文件：

• proguard-android.txt
• proguard-android-optimize.txt

这两个文件都在SDK的路径下。使用getDefaultProguardFile()可以获取这些文件的完整路径。它们除了是否要进行优化之外，其它都是相同的。