3.4.2 构建类型

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

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

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

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

  1. android {
  2. buildTypes {
  3. debug {
  4. applicationIdSuffix ".debug"
  5. }
  6. jnidebug.initWith(buildTypes.debug)
  7. jnidebug {
  8. packageNameSuffix ".jnidebug"
  9. jniDebuggable true
  10. }
  11. }
  12. }

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

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

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

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

属性名 debug时的默认值 release或者其他类型的默认值
debuggable true false
jniDebuggable false false
renderscriptDebuggable false false
renderscriptOptimLevel 3 3
applicationIdSuffix null null
versionNameSuffix null null
signingConfig android.signingConfigs.debug null
zipAlignEnabled false true
minifyEnabled false false
proguardFile N/A (只能设置) N/A (只能设置)
proguardFiles N/A (只能设置) N/A (只能设置)

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

  1. src/<buildtypename>/

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

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

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

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

assembleDebugassembleRelease 这两个任务已经讲过了,这里讲的是他们是从哪来的。是在 debugrelease 这两个 Build Types 被预先创建的时候。

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

可能使用到的情况:

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

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

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