来源：jayfeng
链接：http://www.jayfeng.com/2015/11/07/Android
相关阅读：
新一代Android渠道打包工具：1000个渠道包只需要5秒
下一代Android渠道打包工具－－100个渠道包只需要10秒钟
使用gradle打包apk已经成为当前主流趋势，我也在这个过程中经历了各种需求，并不断结合gradle新的支持，一一改进。在此，把这些相关的东西记录，做一总结。
1. 替换AndroidManifest中的占位符
我想把其中的${app_label}替换为@string/app_name
android{
defaultConfig{
manifestPlaceholders = [app_label:"@string/app_name"]
}
如果只想替换debug版本：
android{
buildTypes {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
}
release {
}
}
}
更多的需求是替换渠道编号：
android{
productFlavors {
// 把dev产品型号的apk的AndroidManifest中的channel替换dev
"dev"{
manifestPlaceholders = [channel:"dev"]
}
}
}
2. 独立配置签名信息
对于签名相关的信息,直接写在gradle当然不好,特别是一些开源项目，可以添加到gradle.properties:
RELEASE_KEY_PASSWORD=xxxx
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks
然后在build.gradle中引用即可：
android {
signingConfigs {
release {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
}
}
如果不想提交到版本库，可以添加到local.properties中，然后在build.gradle中读取。
3. 多渠道打包
多渠道打包的关键之处在于，定义不同的product flavor, 并把AndroiManifest中的channel渠道编号替换为对应的flavor标识：
android {
productFlavors {
dev{
manifestPlaceholders = [channel:"dev"]
}
official{
manifestPlaceholders = [channel:"official"]
}
// ... ...
wandoujia{
manifestPlaceholders = [channel:"wandoujia"]
}
xiaomi{
manifestPlaceholders = [channel:"xiaomi"]
}
"360"{
manifestPlaceholders = [channel:"360"]
}
}
注意一点，这里的flavor名如果是数字开头，必须用引号引起来。
构建一下，就能生成一系列的Build Variant了:
devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release
其中debug, release是gradle默认自带的两个build type, 下一节还会继续说明。
选择一个，就能编译出对应渠道的apk了。
4. 自定义Build Type
前面说到默认的build type有两种debug和release，区别如下：
// release版本生成的BuildConfig特性信息
public final class BuildConfig {
public static final boolean DEBUG = false;
public static final String BUILD_TYPE = "release";
}
// debug版本生成的BuildConfig特性信息
public final class BuildConfig {
public static final boolean DEBUG = true;
public static final String BUILD_TYPE = "debug";
}
现在有一种需求，增加一种build type，介于debug和release之间，就是和release版本一样，加小编微信：AMEPRE，但是要保留debug状态（如果做过rom开发的话，类似于user debug版本），我们称为preview版本吧。
其实很简单：
android {
signingConfigs {
debug {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
preview {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
release {
storeFile file(RELEASE_STORE_FILE)
storePassword RELEASE_STORE_PASSWORD
keyAlias RELEASE_KEY_ALIAS
keyPassword RELEASE_KEY_PASSWORD
}
}
buildTypes {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
}
release {
manifestPlaceholders = [app_label:"@string/app_name"]
}
preview{
manifestPlaceholders = [app_label:"@string/app_name_preview"]
}
}
}
另外，build type还有一个好处，如果想要一次性生成所有的preview版本，执行assemblePreview即可，debug和releae版本同理。
5. build type中的定制参数
上面我们在不同的build type替换${app_label}为不同的字符串，这样安装到手机上就能明显的区分出不同build type的版本。
除此之外，可能还可以配置一些参数，我这里列几个我在工作中用到的：
android {
debug {
manifestPlaceholders = [app_label:"@string/app_name_debug"]
applicationIdSuffix ".debug"
minifyEnabled false
signingConfig signingConfigs.debug
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
release {
manifestPlaceholders = [app_label:"@string/app_name"]
minifyEnabled true
shrinkResources true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
preview{
manifestPlaceholders = [app_label:"@string/app_name_preview"]
applicationIdSuffix ".preview"
debuggable true // 保留debug信息
minifyEnabled true
shrinkResources true
signingConfig signingConfigs.preview
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
这些都用的太多了，稍微解释一下：
// minifyEnabled 混淆处理
// shrinkResources 去除无用资源
// signingConfig 签名
// proguardFiles 混淆配置
// applicationIdSuffix 增加APP ID的后缀
// debuggable 是否保留调试信息
// ... ...
6. 多工程全局配置
随着产品渠道的铺开，往往一套代码需要支持多个产品形态，这就需要抽象出主要代码到一个Library，然后基于Library扩展几个App Module。
相信每个module的build.gradle都会有这个代码：
android {
compileSdkVersion 22
buildToolsVersion "23.0.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 22
versionCode 34
versionName "v2.6.1"
}
}
当升级sdk、build tool、target sdk等，几个module都要更改，非常的麻烦。最重要的是，很容易忘记，最终导致app module之间的差异不统一，也不可控。
强大的gradle插件在1.1.0支持全局变量设定，一举解决了这个问题。
先在project的根目录下的build.gradle定义ext全局变量:
ext {
compileSdkVersion = 22
buildToolsVersion = "23.0.1"
minSdkVersion = 10
targetSdkVersion = 22
versionCode = 34
versionName = "v2.6.1"
}
然后在各module的build.gradle中引用如下：
android {
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
defaultConfig {
applicationId "com.xxx.xxx"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName
}
}
然后每次修改project级别的build.gradle即可实现全局统一配置。
7. 自定义导出的APK名称
默认android studio生成的apk名称为app-debug.apk或者app-release.apk，当有多个渠道的时候，需要同时编出50个渠道包的时候，就麻烦了，不知道谁是谁了。
