最近在公司项目中需要利用同一套代码打包出具有不同皮肤和有一些功能差异的两个apk包，于是学习了一下Android Studio中利用gradle框架进行多渠道或多apk打包。
认识build.gradle脚本
Gradle是一种构建项目的框架，兼容Maven、Ant，为Java项目提供了很多插件去实现打包功能。Android Studio也集成了gradle构建项目框架，在一个Android Studio project中会自动生成一些gradle script文件，如下图所示。
展开Gradle Scripts我们可以看到里面有两个build.gradle文件和一个settings.gradle文件，其中的build.gradle(Project: GradleTestDemo)文件是整个工程的build文件，而build.gradle(Module: app)文件是工程下的一个Module的build文件，settings.gradle用于配置project，标明其下有几个module，比如这里包含一个:app module。
在Android Studio工程目录结构中一个Project可以有多个Module，Project可以理解为Eclipse下的一个Workspace，Module可以理解为Eclipse下的Project。当我们用Android Studio建立一个默认的工程时，它自动为我们建立了一个名字为app的默认Module。所以我们容易理解，一个Android Studio工程会有一个工程级别的build.gradle文件，同时如果有N个Module，就会有N个Module级别的build.gradle文件。
settings.gradle文件
settings.gradle 文件位于项目根目录，用于指示 Gradle 在构建应用时应将哪些模块包括在内。对大多数项目而言，该文件很简单，只包括以下内容：
include ':app'
Project的build.gradle文件
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
// 指定依赖版本号为2.3.0的Android gradle build插件
classpath 'com.android.tools.build:gradle:2.3.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
//为所有的工程的repositories配置为jcenter
allprojects {
repositories {
jcenter()
}
}
//执行清除project的output文件的任务
task clean(type: Delete) {
delete rootProject.buildDir
}
在Project根目录下的build.gradle文件被称为顶级构建文件，为整个project的所有module配置build所依赖的一些资源及插件，顶级构建文件使用 buildscript {} 代码块来定义项目中所有模块共用的 Gradle 存储区和依赖项，比如指定依赖android gradle build插件的版本。在顶级构建文件中还可以配置一些project共用的构建任务，比如上面示例代码中clean是一个delete类型的task，意思是在执行打包脚本前做一个清理工作，把项目输出文件夹中的文件先全部清理干净。
Module的build.gradle文件
//为这个工程的构建指定Android插件， 'com.android.application'这个插件中提供了下面要用的android{}闭包
//如果是一个android library，那么这里应写成 apply plugin: ‘com.android.library’
apply plugin: 'com.android.application'
android {
/**
* 指定Gradle编译所需要的Android API版本号，这表明当前App可以使用这个版本号以及低于这个版本的
* SDK版本中的API
*/
compileSdkVersion 25
//指定基于哪个版本的构建工具进行构建
buildToolsVersion '25.0.0'
/**
* 在defaultConfig {} 闭包中可以为所有构建变量设置默认值，这些设置可以在编译系统中动态地复写一些
* main/AndroidManifest.xml中的属性，可以通过配置productFlavors来为不同版本的apk赋属性值
* 比如applicationId是配置包名的，versionCode是版本号，versionName是版本名称等
* 如果没有其他的配置覆盖，就会使用这里的值
*/
defaultConfig {
applicationId "com.study.gradletestdemo"
minSdkVersion 15
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
/**
* 在buildTypes {} 闭包中可以配置多种构建类型，默认有两种构建类型：debug、release
* 还可以配置自定义的构建类型，比如internal 国内类型、external 国外类型等
* 这里做release类型下配置了代码混淆文件
*/
buildTypes {
release {
minifyEnabled false
//指定混淆配置文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
/**
* productFlavors {} 闭包用于定义多种定制产品，在这里为不同版本类型的产品设置构建属性，
* 它们将覆盖defaultConfig{}中设置的相关值，Product flavors不是Gradle默认的构建设置项，一般用于
* 多渠道或多apk打包时自定义设置，下面示例代码中设置了两个产品，分别用于免费和收费发布，
* 这样构建出来的apk可以在同一个应用市场或同一台Android设备上同时存在
*/
productFlavors {
free {
applicationId 'com.study.gradletestdemo.free'
}
paid {
applicationId 'com.study.gradletestdemo.paid'
}
}
/**
* splits {} 闭包用于构建只支持特定屏幕像素密度或ABI的Android设备的apk
*/
splits {
// Screen density split settings
density {
// Enable or disable the density split mechanism
enable false
// Exclude these densities from splits
exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
}
}
dependencies {
//依赖工程libs目录下所有的jar包，也可以指定具体的每一个jar包，而不是采用*.jar通配符匹配的方式
compile fileTree(dir: 'libs', include: ['*.jar'])
//通过"包名:工程名:版本号"的形式来依赖当前工程需要的第三方类库
compile 'com.android.support:appcompat-v7:25.0.0'
compile 'com.android.support.constraint:constraint-layout:1.0.0-beta2'
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
//测试依赖库
testCompile 'junit:junit:4.12'
}
}
在每个 <project>/<module>/ 目录下的build.gradle文件称为模块级构建文件，用于配置适用于其所在模块的构建设置。可以通过配置这些构建设置来提供自定义打包选项（例如附加构建类型和产品定制），以及替换 main/AndroidManifest.xml或顶级 build.gradle 文件中的设置。
用Gradle进行多版本打包
用Gradle进行多版本打包主要有两个使用场景：
1、同一个应用的不同版本。比如一个免费的版本和一个付费的专业版本。
2、同一个应用被打包成多个不同的apk以发布到Google Play商店。
综合第1条和第2条还可以变幻出其他需求的多版本打包。
从上文中描述的Module的build.gradle文件可以知道Gradle通过设置buildTypes、productFlavors或splits来构建同一个工程的多种不同版本的应用，本文不讨论splits的详细用法，它的主要用途如上面的示例中说明。正如上文的示例代码及注释所表达的，一个Build Type设置对应生成一个apk文件，一个Product Flavor设置也对应一个apk文件，所以每一个组合(Build Type, Product Flavor)就生成一个特定版本的apk。以默认的 debug 和 release Build Types 为例，上面的例子会生成四个 Build Variants：
多渠道打包
多版本打包在国内Android开发比较典型的应用场景就是多渠道打包，由于国内做Android应用分发的市场很多，一般公司开发一款App如果要在国内发布就需要覆盖几乎所有主流的应用市场，这时为了做一些用户量统计以及其他行为分析就需要为不同的应用市场出不同的App包。
在国内Android市场多渠道出包往往需要借助友盟统计来进行渠道分析，这种多渠道打包可能apk的所有信息一致，只需要配置包所带的渠道信息，可以通过productFlavors配置轻松搞定。
首先，在AndroidManifest.xml文件中设置置友盟账号信息，以及通过占位符设置动态渠道变量
<meta-data android:value="Channel ID" android:name="UMENG_CHANNEL"/>
<meta-data android:name="UMENG_CHANNEL" android:value="${UMENG_CHANNEL_VALUE}" />
然后，在build.gradle设置productFlavors
//假定我们需要打包的渠道包括华为市场、360、小米、百度、豌豆荚
android {
productFlavors {
huawei {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "huawei"]
}
xiaomi {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"]
}
qh360 {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "qh360"]
}
baidu {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "baidu"]
}
wandoujia {
manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"]
}
}
}
//可以批量修改打包渠道配置
android {
productFlavors {
huawei {}
xiaomi {}
qh360 {}
baidu {}
wandoujia {}
}
productFlavors.all {
flavor -> flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
}
}
按上面的方式配置好以后即可以执行多渠道的打包了。
多apk打包
多apk打包的需求比较多样，比如构建应用的免费版本（只提供有限的内容）和付费版本（提供更多内容），构建演示版本和正式发布版本，还可以针对不同设备、根据API级别或者针对不同的目标用户等出不同的包。这种多apk打包可以通过productFlavors配置不同的applicationId、minSdkVersion、targetSdkVersion等
productFlavors {
free {
applicationId 'com.study.gradletestdemo.free'
minSdkVersion 14
targetSdkVersion 21
versionCode 1
versionName "1.0.0"
}
paid {
applicationId 'com.study.gradletestdemo.paid'
minSdkVersion 15
targetSdkVersion 22
versionCode 10
versionName "5.0.2"
}
}
多apk打包除了需要配置以上信息，可能不同的apk需要的代码或资源文件也会有差异，自定义每个构建变体及其功能和资源，就需要了解如何创建和管理源集(sourceSets)。
Android Studio 默认会创建 main/ 源集及相关目录，用于存储所有构建变体可以共享的一切资源。同时我们可以创建新的源集来确切控制 Gradle 要为特定的构建类型、产品定制和构建变体来编译和打包哪些文件。例如，在 main/ 源集中定义共有的基本功能，使用产品定制源集针对不同的客户更改应用的品牌，或者仅针对使用调试构建类型的构建变体包含特殊的权限和日志记录功能。
Gradle 要求按照与 main/ 源集类似的特定方式组织源集文件和目录。当我们在productFlavors{}中创建了新的构建变体时，Android Studio 不会自动创建源集目录，可以通过下面的步骤创建：
- 打开 Project 窗格并从窗格顶端的下拉菜单中选择 Project 视图。
- 导航至 MyProject/app/src/。
- 右键点击 src 目录并选择 New > Folder > Java Folder。
- 从 Target Source Set 旁边的下拉菜单中，选择需要创建源集的build flavor名称。
- 点击 Finish。
Android Studio 将会为我们选择的构建类型创建源集目录，然后在该目录内部创建 java/ 目录。或者，也可以让 Android Studio 在为特定的构建变体创建新文件时创建相关目录，例如需要为free产品创建定义特殊颜色值的colors.xml文件：
- 在该 Project 窗格中，右键点击 src 目录并选择 New > XML > Values XML File。
- 为 XML 文件输入colors。
- 从 Target Source Set 旁边的下拉菜单中，选择free。
- 点击 Finish。
由于free被指定为目标源集，Android Studio 会在创建 XML 文件时自动创建必要的目录，创建后的目录如下：
同样的方式，也可以在java目录下添加特定产品自定义的一些代码文件，这样利用源集来为不同的定制产品开发特定功能，然后再统一打包发布。
配置签名信息
首先生成一份签名文件，可以用Android Studio中的New Key Store图形界面工具创建一份签名文件
1、在Android studio图形界面中配置
在Android Studio菜单栏点击Build菜单–>Generate signed APK–>选择key，并输入密码
2、在gradle文件中配置
signingConfigs {
release {
storeFile file("myreleasekey.keystore")
storePassword "password"
keyAlias "my_key"
keyPassword "password"
}
}
执行打包
1、Android studio图形界面功能操作
在上面配置签名信息的图形界面操作中选择了Key过后，点击Next，在面板中选择要打包的Flavors，并选择签名版本，然后点击Finish。打包成功后的apk文件在 GradleTestDemo/app/ 目录下
2、用命令打包
除了可以用Android Studio很直观方便的图形界面进行打包，作为程序员还需要会用相应的命令行。用命令行打包主要是运用gradlew命令，可以同时为所有定制产品所有构建类型进行打包，也可以指定为某一个定制产品的某种构建类型打包。例如，在Android Studio的Terminal面板中输入gradlew assembleRelease命令，将生成所有定制产品的release版本的apk文件，这些文件会默认生成到 app/build/outputs/apk/ 目录下。如果没有配置签名信息，生成的apk文件名后面会加上"-unsigned"。
总结
用gradle进行多变种打包还有诸多细节可以深入讨论，这里只是总结了多渠道、多apk打包的主要操作流程及相关知识点，在实际工作中有更明确的需求时可以以此为线索深入学习。
Thanks To
配置构建变体
Gradle Plugin User Guide
手把手教你AndroidStudio多渠道打包
Android Studio Gradle实践之多渠道自动化打包+版本号管理
