3.4.2 构建类型

默认情况下，Android plugin 会自动的设置工程，构建 release 和 debug 两个版本。
他们主要的差异主要在于是否可以在设备上调试应用以及APK如何签名。

debug 版本会被使用已知的名称/密码自动生成的密钥/证书签名。release 版本在构建过程中不会被签名，需要构建后再签名。

这些配置可以通过一个叫 BuildType 配置。默认情况下，已经创建了 debug 和 release 这两个实例。

Android plugin 允许自定义这两个示例，并且可以创建其他的 Build Types 。这些是可以在 buildTypes DSL容器中配置完成:

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

以上的片段实现了以下几点：

• 配置了默认的 debug 构建类型：
  • 设置包名为 <app appliationId>.debug 以便可以在同一设备上同时安装 debug 和 release 两个版本的APK
• 创建一个叫 jnidebug 新的 Build Types ，并且配置它作为 debug 构建类型的一个副本
• 然后再配置 jnidebug ，启用 JNI 组件的 debug 构建，并且添加一个不同的包名后缀

创建一个新的 Build Types 很简单，只需要在 buildTypes 容器下添加一个元素，然后调用 initWith() 或者使用一个闭包配置它。

这里有一些可能用到的属性以及他们的默认值：

除了这些属性外， 代码和资源也会影响到 Build Types 。
对于每一个 Build Type,都会创建一个新的匹配的 sourceSet ，默认位置是

src/<buildtypename>/

这意味着 Build Type 的名字不能是 main 和 androidTest (这两个已经被插件占用)，并且他们相互之间的名字必须唯一。

和其他的 source sets 一样，Build Type 的 source set 的位置可以被重定向：

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

此外，对于每一个 Build Type ，都会新创建assemble\任务。

assembleDebug 和 assembleRelease 这两个任务已经讲过了，这里讲的是他们是从哪来的。是在 debug 和 release 这两个 Build Types 被预先创建的时候。

提示：记得你可以通过输入 gradle aJ 来运行assembleJnidebug任务哦。

可能使用到的情况：

• 在 debug 模式下需要，但是在 release 下不需要的权限
• 自定义 debug 的实现
• 微 debug 默认使用不同的资源（比如一个资源的值是由签名的证书决定的）

BuildType 的代码/资源主要通过以下方式使用：

• manifest 被合并进 app 的 manifest
• 代码仅仅是作为一个额外的 source 文件夹(译者注：其实和自己新建一个 source 文件夹，然后在这个文件夹下新建包和类一样)
• 资源会覆盖 main 里的资源，替换现有的值