自定义构建 - 构建类型
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() 或者使用一个闭包配置它。
这里有一些可能用到的属性以及他们的默认值:
属性名 | 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 ,默认位置是
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 里的资源,替换现有的值