- Gradle是个构建系统，能够简化你的编译、打包、测试过程。熟悉Java的同学，可以把Gradle类比成Maven。
- Gradle Wrapper的作用是简化Gradle本身的安装、部署。不同版本的项目可能需要不同版本的Gradle，手工部署的话比较麻烦，而且可能产生冲突，所以需要Gradle Wrapper帮你搞定这些事情。Gradle Wrapper是Gradle项目的一部分。
- Android Plugin for Gradle是一堆适合Android开发的Gradle插件的集合，主要由Google的Android团队开发，Gradle不是Android的专属构建系统，但是有了Android Plugin for Gradle的话，你会发现使用Gradle构建Android项目尤其的简单。
另外需要说明的一点是Gradle、Gradle Wrapper与Android Plugin for Gradle不一定要和Android Studio一起使用，你可以完全脱离Android Studio，使用三者独立进行Android项目的构建。下面是三者官方的指导文档（从地址可以看出Gradle Wrapper是Gradle项目的一部分）：
- Gradle: https://docs.gradle.org/current/userguide/userguide_single.html
- Gradle Wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.html
- Android Plugin for Gradle: https://developer.android.com/studio/build/index.html
可以看到一个gradle/wrapper目录，其中有两个文件：gradle-wrapper.jar/gradle-wrapper.properties，gradle-wrapper.jar是Gradle Wrapper的主体功能包。在Android Studio安装过程中产生gradle-wrapper.jar（如果默认安装的话会在C:\Program Files\Android\Android Studio\plugins\android\lib\templates\gradle\wrapper\gradle\wrapper\gradle-wrapper.jar）。然后每次新建项目，会将gradle-wrapper.jar拷贝到你的项目的gradle/wrapper目录中。gradle-wrapper.properties文件主要指定了该项目需要什么版本的Gradle，从哪里下载该版本的Gradle，下载下来放到哪里，如下图所示：
其中GRADLE_USER_HOME一般指~/.gradle，从图示项目中可以知道我要使用gradle-4.1版本，从https://services.gradle.org/distributions/gradle-4.1-all.zip下载，下载到本地的~/.gradle/wrapper/dists目录。那是不是各个项目的Gradle都要通过Gradle Wrapper下载，能不能所有的项目共用一个Gradle？这样理论上是可以的，但是由于Gradle本身不一定保持完全的兼容性，所以新老项目共用一个Gradle有时可能会遇到意想不到的问题。指定对应版本的Gradle，而不通过Gradle Wrapper下载的设置方式是勾选如下图中的Use local gradle distribution，同时指定Gradle home：
Gradle对应版本下载完成之后，Gradle Wrapper的使命基本完成了，Gradle会读取build.gradle文件，该文件中指定了该项目需要的Android Plugin for Gradle版本是什么，从哪里下载该版本的Android Plugin for Gradle。如下图所示：
从图示项目中可以知道我们要使用3.0.1版本，从google和jcenter处下载，那么下载到我们本地的哪里呢？它会下载到~\.gradle\caches\modules-2\files-2.1\com.android.tools.build中。有时候大家网络装填不好，选择下图中的Offline work时可能出现"No cached version of com.android.tools.build:gradle:xxx available for offline mode"问题，此时你只要将对应版本的Android Plugin for Gradle下载到本地的C:\Program Files\Android\Android Studio\gradle\m2repository\com\android\tools\build中即可。
defaultConfig{ } 默认配置，是ProductFlavor类型。它共享给其他ProductFlavor使用
sourceSets{ } 源文件目录设置，是AndroidSourceSet类型。
buildTypes{ } BuildType类型
signingConfigs{ } 签名配置，SigningConfig类型
productFlavors{ } 产品风格配置，ProductFlavor类型
testOptions{ } 测试配置，TestOptions类型
aaptOptions{ } aapt配置，AaptOptions类型
lintOptions{ } lint配置，LintOptions类型
dexOptions{ } dex配置，DexOptions类型
compileOptions{ } 编译配置，CompileOptions类型
packagingOptions{ } PackagingOptions类型
jacoco{ } JacocoExtension类型。 用于设定 jacoco版本
splits{ } Splits类型
A：占位符
在使用友盟进行渠道统计常用的做法是 使用占位符，比如我们可以在AndroidManifest.xml文件使用meta-data进行信息的配置。
然后使用的话，如下图：
B：签名
签名，是android标签内大家经常使用到的，由于Android 7.0加入了新的签名机制(也就是V2签名)针对这个问题的解决方式可以参考这篇文章 Android-V1、V2签名，因此我们可以直接在debug和release标签中加入v1SigningEnabled true 、v2SigningEnabled true 规避使用风险
下面是加入新签名机制以及原来大家比较熟悉的写法：
这里还给大家提供一种关于签名信息的写法（拓展性比第一种较强），首先，我们在app文件的根目录下定义一个文件 signing.properties ，然后写上具体的属性值 （具体的说明如代码截图）
由于Gradle是一门脚本，既然是脚本那么它肯定内置了一些函数（注意：Gradle的函数是在app gradle文件内置的标签外 进行编写）给我们操作调用。因为将签名信息写到了这里的配置文件，所以可以通过Gradle去读取信息 然后进行赋值，代码如下：
有了读取签名文件的函数，我们就可以进行Alias、password的赋值。
C：多渠道包配置
Android Studio给我们提供的多渠道打包方案是使用productFlavors标签配置渠道信息，但是新版本下直接使用这个productFlavors标签会报错，工具要求我们在defaultConfig标签下新增flavorDimensions，如果不使用flavorDimensions关键字，编译会报错：
D：自定义apk输出路径
传统的打包操作流程执行编译以及签名后生成的apk默认是 项目 \build\outputs\apk 这个路径下面，那现在我想指定apk输出的文件位置（比如我现在想让这个apk输出到 c盘下面的out_apk文件夹下）该如何操作？
其中这里的红色矩形是对上面签名第二种方法的补充说明，这里的buildTypes标签需要写在signingConfigs标签后面，否则很容易编译错误，这个是笔者遇到的问题；蓝色矩形的代码块主要是首先判断是debug还是release版本，如果是release版本就将apk输入到这个指定盘符。
好了，说了这么多gradle文件的配置，下面就开始我们的打包工作。
首先是我们的传统打签名包：
点击Android Studio 顶部Tab ， Build —— Generate Sign Apk 然后出现下面的界面：
配置好基本信息以后，点击next，勾选V1、V2等一些配置即可完成签名打包。
第二种：在Android Studio 底部Tab的 Terminal窗口 输入 gradle a 命令（本质就是dos操作），来帮助我们打包
以上两种打包方式都是传统的打包方式，那么有没有更简单的操作？这种简单的操作类似我 在PC上面点击一个快捷方式就给我生成apk包？答案在开头已经说了是有的。
A：首先，我们在项目根目录下创建一个指定的文件夹(用于编译跑脚本用)，这个文件一般定义为 .config文件（记住：前面有个 . ）
B：然后，在这个文件夹内创建 build.bat文件。可能你会问什么是bat文件？bat文件是dos下的批处理文件。批处理文件是无格式的文本文件，它包含一条或多条命令。当我们双击bat文件的时候，系统就会调用cmd.exe按照该文件中各个命令出现的顺序来逐个运行它们。所以，我们只需要在这个bat文件里面写下相应的命令进行操作即可
C：既然现在我们需要在bat文件里面写命令，那么gradle里面有那些可以执行的打包命令？下面是收集到的一些资料，命令如下：
1：编译所有productFlavor及对应所有buildType的apk：
gradle assemble //仅仅执行项目打包所必须的任务集
gradle build //执行项目打包所必须的任务集,以及执行自动化测试,所以会较慢
如果当前Project包含多个Module,在Project根目录执行gradle assemble会编译所有的Module
2：编译指定productFlavor及buildType的apk
gradle assemble[productFlavor][buildType] //如果缺失某参数,则会把该参数的所有配置都进行编译,即如果运行gradle assembleflavor,则会编译出flavor所有buildType的apk
例如：
gradle assemble
gradle assembleflavorRelease
gradle assembleflavorDebug
注意：gradle支持命令缩写，上面两个命令也可以写成如下格式
$gradle a
$gradle ass
$gradle aR
$gradle assflavorR
$gradle aD
$gradle assflavorD
D：既然dos命令确定了，我们就可以写bat文件进行测试了：
E：接下来我们就可以将这个build.bat文件，设置为桌面快捷方式，然后双击，双击以后会弹出cmd窗口进行打包然后去指定的文件夹拿到apk即可。
以上步骤的前提是你需要配置好Gradle运行环境、熟悉Gradle的基本命令以及必要的耐心和不怕失败的勇气。
- 根目录下的 build.gradle
1） repositories 闭包，声明了 jcenter() 的配置；
2） dependencies 闭包，声明了一个 Gradle 插件。
buildscript {
repositories { //repositories闭包
google()
jcenter() //代码托管库：设置之后可以在项目中轻松引用jcenter上的开源项目
}
dependencies { //dependencies闭包
classpath 'com.android.tools.build:gradle:3.0.0' ////声明gradle插件，插件版本号为3.0.0
//gradle是一个强大的项目构建工具，不仅可以构建Android，还可以构建java，C++等
//此处引用android的插件
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
google()
jcenter() //代码托管库：设置之后可以在项目中轻松引用jcenter上的开源项目
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
- app 目录下的build.gradle
1） apply plugin，声明是 Android 应用程序还是库模块；
2） android 闭包，配置项目构建的各种属性，compileSDKVersion 用于指定项目的变异 SDK 版本， buildToolsVersion 用户指定项目构建工具的版本。
defaultConfig 闭包：默认配置、应用程序包名、最小sdk版本、目标sdk版本、版本号、版本名称；
buildTypes 闭包：指定生成安装文件的配置，是否对代码进行混淆；
signingConfigs 闭包：签名信息配置；
sourceSets 闭包：源文件路径配置；
lintOptions 闭包：lint 配置；
3） dependencies 闭包，指定当前项目的所有以来关系，本地以来，库依赖以及远程依赖；
4） repositories 闭包，仓库配置。
// 声明是Android程序，
// com.android.application 表示这是一个应用程序模块,可直接运行
// com.android.library 标识这是一个库模块，是依附别的应用程序运行
apply plugin: 'com.android.application'
android {
// 程序在编译的时候会检查lint，有任何错误提示会停止build，我们可以关闭这个开关
lintOptions {
// 即使报错也不会停止打包
abortOnError false
// 打包release版本的时候是否进行检测
checkReleaseBuilds false
}
// 编译sdk的版本，也就是API Level，例如API-19、API-20、API-21等等。
compileSdkVersion 27
// build tools的版本，其中包括了打包工具aapt、dx等等。
// 这个工具的目录位于你的sdk目录/build-tools/下
buildToolsVersion '27.0.3'
//关闭Android Studio的PNG合法性检查
aaptOptions.cruncherEnabled = false
aaptOptions.useNewCruncher = false
defaultConfig { // 默认配置
applicationId "com.demo.test" // 应用程序的包名
minSdkVersion 22 / 最小sdk版本，如果设备小于这个版本或者大于maxSdkVersion将无法安装这个应用
targetSdkVersion 27 // 目标sdk版本，充分测试过的版本（建议版本）
versionCode 1 // 版本号，第一版是1，之后每更新一次加1
versionName "1.0" // 版本名，显示给用户看到的版本号
archivesBaseName = "demo-$versionName" // 指定打包成Jar文件时候的文件名称
ndk {
moduleName "testwifisafe" // 设置库(so)文件名称
ldLibs "log", "z", "m", "jnigraphics", "android"
// 引入库，比如要用到的__android_log_print
abiFilters "armeabi", "x86", "armeabi-v7a" // "x86" 显示指定支持的ABIs
cFlags "-std=c++11 -fexceptions" // C++11
stl "gnustl_static"
}
// 当方法数超过65535(方法的索引使用的是一个short值，
// 而short最大值是65535)的时候允许打包成多个dex文件，动态加载dex。这里面坑很深啊
multiDexEnabled true
// Instrumentation单元测试
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
// 默认的一些文件路径的配置
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml' // 指定清单文件
res.srcDirs = ['res'] // 指定res资源目录
assets.srcDirs = ['assets'] // asset资源目录
jni.srcDirs 'src/main/jni' // jni代码目录
jniLibs.srcDir 'src/main/jniLibs' // jni库目录
java.srcDirs = ['src'] // 指定java源代码目录
resources.srcDirs = ['src'] // 指定resource目录
aidl.srcDirs = ['src'] // 指定aidl目录
renderscript.srcDirs = ['src'] // 指定source目录
}
debug.setRoot('build-types/debug') // 指定debug模式的路径
release.setRoot('build-types/release') // 指定release模式的路径
}
// multiDex的一些相关配置，这样配置可以让你的编译速度更快
dexOptions {
// 让它不要对Lib做preDexing
preDexLibraries = false
// 开启incremental dexing,优化编译效率，这个功能android studio默认是关闭的。
incremental true
javaMaxHeapSize "4g" // 增加java堆内存大小
}
signingConfigs {// 签名配置
release {// 发布版签名配置
storeFile file("fk.keystore") // 密钥文件路径
storePassword "123456" // 密钥文件密码
keyAlias "fk" // key别名
keyPassword "123456" // key密码
}
debug {// debug版签名配置
storeFile file("fk.keystore")
storePassword "123456"
keyAlias "fk"
keyPassword "123456"
}
}
// 指定生成安装文件的配置，常有两个子包:release,debug，注：直接运行的都是debug安装文件
buildTypes {
// release版本的配置，即生成正式版安装文件的配置
release {
zipAlignEnabled true // 是否支持zip
shrinkResources true // 移除无用的resource文件
minifyEnabled false // 是否对代码进行混淆，true表示混淆
// 指定混淆时使用的规则文件；
// proguard-android.txt指所有项目通用的混淆规则，proguard-rules.pro当前项目特有的混淆规则
// release的Proguard默认为Module下的proguard-rules.pro文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
debuggable false //是否支持调试
//ndk的一些配置
ndk {
// cFlags "-std=c++11 -fexceptions -O3 -D__RELEASE__" // C++11
// platformVersion = "19"
moduleName "hebbewifisafe" // 设置库(so)文件名称
ldLibs "log", "z", "m", "jnigraphics", "android"
// 引入库，比如要用到的__android_log_print
abiFilters "armeabi", "x86", "armeabi-v7a"// "x86"
cFlags "-std=c++11 -fexceptions" // C++11
stl "gnustl_static"
}
// 采用动态替换字符串的方式生成不同的 release.apk （3.0之后版本的修改方式）
applicationVariants.all { variant ->
variant.outputs.all { output ->
if (!variant.buildType.isDebuggable()) {
// 获取签名的名字 variant.signingConfig.name
// 要被替换的源字符串
def sourceFile = "app-release";
// 替换的字符串
def replaceFile = "Demo-V${variant.versionName}.${releaseTime()}"
outputFileName = output.outputFile.name.replace(sourceFile, replaceFile)
}
}
}
jniDebuggable false // 关闭jni调试
}
debug { // debug版本的配置
minifyEnabled false
zipAlignEnabled true
shrinkResources true // 移除无用的resource文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
debuggable true
// jniDebuggable true
ndk {
cFlags "-std=c++11 -fexceptions -g -D __DEBUG__" // C++11
}
jniDebuggable true
}
}
packagingOptions {
exclude 'META-INF/ASL2.0'
exclude 'META-INF/LICENSE'
exclude 'META-INF/NOTICE'
exclude 'META-INF/MANIFEST.MF'
}
compileOptions {
// 在这里你可以进行 Java 的版本配置，
// 以便使用对应版本的一些新特性
}
productFlavors {
// 在这里你可以设置你的产品发布的一些东西，
// 比如你现在一共软件需要发布到不同渠道，
// 且不同渠道中的包名不同，那么可以在此进行配置；
// 甚至可以设置不同的 AndroidManifest.xml 文件。
hebbe {
}
googlePlay {
}
solo {
}
}
productFlavors.all {
flavor -> flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name]
}
// 所谓ProductFlavors其实就是可定义的产品特性，
// 配合 manifest merger 使用的时候就可以达成在一次编译
// 过程中产生多个具有自己特性配置的版本。
// 上面这个配置的作用就是，为每个渠道包产生不同的 UMENG_CHANNEL_VALUE 的值。
}
// 指定当前项目的所有依赖关系：本地依赖、库依赖、远程依赖
// 本地依赖：可以对本地 Jar 包或目录添加依赖关系
// 库依赖：可以对项目中的库模块添加依赖关系
// 远程依赖：可以对 jcenter 库上的开源项目添加依赖
// 标准的远程依赖格式是 域名:组织名:版本号
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar']) // 本地依赖
// 远程依赖，com.android.support是域名部分，appcompat-v7是组名称，26.1.0是版本号
implementation 'com.android.support:appcompat-v7:26.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.0.2'
implementation project(':hello') // 库依赖
testImplementation 'junit:junit:4.12' // 声明测试用列库
androidTestImplementation 'com.android.support.test:runner:1.0.1'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}
// 声明是要使用谷歌服务框架
apply plugin: 'com.google.gms.google-services'
// 第三方依赖库的本地缓存路径
task showMeCache << {
configurations.compile.each { println it }
}
// 使用maven仓库。android有两个标准的library文件服务器，一个jcenter一个maven。两者毫无关系。
// jcenter有的maven可能没有，反之亦然。
// 如果要使用jcenter的话就把mavenCentral()替换成jcenter()
repositories {
mavenCentral()
}
205 // 获取日期方法
def releaseTime() {
return new Date().format("MMdd.HHmm")
}
gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-2.14.1-all.zip
//主要是要上面的地址改成自己本地有的版本
Mac系统默认下载到：/Users/(用户名)/.gradle/caches/modules-2/files-2.1
Windows系统默认下载到：C:\Users(用户名).gradle\caches\modules-2\files-2.1
在开发sdk生成jar在eclipse里相对比较容易操作，只要导出class时指定哪里导出就可以，
但在用AndroidStudio开发时要导出jar就没那么容易，需要写gradle脚本，但gradle脚本
的入门成本还是比较高，网上也有打包jar的脚本参考，但大多是通过生成classes.jar重命名
来生成，这样生成的jar是包含工程里所有类的，有时我们需要指定一些包和类来生成jar。
下面是参考脚本：
task clearJar(type: Delete) {
delete 'libs/sdk.jar'
}
task makeJar(type:org.gradle.api.tasks.bundling.Jar) {
//指定生成的jar名
baseName 'sdk'
//从哪里打包class文件
from('build/intermediates/classes/debug/org/cmdmac/cloud/pluginsdk/')
//打包到jar后的目录结构
into('org/cmdmac/cloud/pluginsdk/')
//去掉不需要打包的目录和文件
exclude('test/', 'BuildConfig.class', 'R.class')
//去掉R');}
}
makeJar.dependsOn(clearJar, build)
在build.gradle写上后，只要在命令行执行gradle makeJar就可以在build/libs目录下找到这个jar
如果要实现只打某个包下面的某些子包或者文件可参考如下示例：
task makeSdkJar(type:org.gradle.api.tasks.bundling.Jar) {
baseName 'pluginsdk'
//只打包org.cmdmac下的org.cmdmac.pluginsdk.impl和org.cmdmac.gamecenter,其他子包不会被打包进去
from('build/intermediates/classes/debug/org/cmdmac/') {
include 'pluginsdk/impl'
include 'gamecenter'
}
into('org/cmdmac/')
// exclude('R.class')
// exclude{ it.name.startsWith('R$');}
}
要熟练构建变体，先需要了解Androidstudio是如何来自动化执行和管理构建流程。
构建流程
如图所示，典型 Android 应用模块的构建流程通常依循下列步骤：
- 编译器将您的源代码转换成 DEX（Dalvik Executable) 文件（其中包括运行在 Android 设备上的字节码），将所有其他内容转换成已编译资源。
- APK 打包器将 DEX 文件和已编译资源合并成单个 APK。不过，必须先签署 APK，才能将应用安装并部署到 Android 设备上。
- APK 打包器使用调试或发布密钥库签署您的 APK：
- 如果您构建的是调试版本的应用（即专用于测试和分析的应用），打包器会使用调试密钥库签署您的应用。Android Studio 自动使用调试密钥库配置新项目。
- 如果您构建的是打算向外发布的发布版本应用，打包器会使用发布密钥库签署您的应用。要创建发布密钥库，请阅读在 Android Studio 中签署您的应用。
- 在生成最终 APK 之前，打包器会使用 zipalign 工具对应用进行优化，减少其在设备上运行时的内存占用。
构建流程结束时，您将获得可用来进行部署、测试的调试 APK，或者可用来发布给外部用户的发布 APK。
自定义构建配置
通过Androidstudio我们可以自动构建哪些内容呢？
- 构建类型
- 产品风味
- 构建变体
- 清单条目
- 依赖项
下面详细介绍如何去构建。
配置构建类型(buildTypes)
可以在模块级 build.gradle 文件的 android {} 代码块内部创建和配置构建类型，默认的类型为release和debug。
我们可以在realease项中很方便的对APK进行签名，也可以对applicationId根据类型添加后缀，例如：
//读取签名文件信息
def keystorePropertiesFile = rootProject.file("keystore.properties");
def keystoreProperties = new Properties()
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
android {
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
defaultConfig {
applicationId "com.abupdate.fota_demo_iot"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode 1
versionName verName
}
//签名配置信息
signingConfigs {
config {
storeFile file(keystoreProperties['ReleaseStoreFile'])
storePassword keystoreProperties['ReleaseStorePassword']
keyAlias keystoreProperties['ReleaseKeyAlias']
keyPassword keystoreProperties['ReleaseKeyPassword']
}
}
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
//签名
signingConfig signingConfigs.config
}
debug {
minifyEnabled false
shrinkResources false
//对applicationId根据类型添加后缀
applicationIdSuffix ".debug"
}
}
}
修改后记得点一下工具栏中的同步。
配置产品风味(productFlavors)
创建productFlavor与创建构建类型类似：只需将它们添加到 productFlavors {} 代码块并配置您想要的设置。productFlavor支持与 defaultConfig 相同的属性，这是因为 defaultConfig 实际上属于 ProductFlavor 类。这意味着，您可以在 defaultConfig {} 代码块中提供所有productFlavor的基本配置，每种productFlavor均可更改任何这些默认值，例如 applicationId。
比如，现在我们有两种产品风味，一种为车机产品，一种为手机产品，那么可以这么配置：
productFlavors{
Car{
//根据不同的产品提添加不同的字段，以便在代码中进行判断
buildConfigField("String", "APP_LAUNCH_ACTIVITY", APP_LAUNCH_ACTIVITY_CAR)
buildConfigField("String", "APP_TYPE", APP_TYPE_CAR)
applicationIdSuffix ".car"
versionNameSuffix "-car
}
Phone{
buildConfigField("String", "APP_LAUNCH_ACTIVITY", APP_LAUNCH_ACTIVITY_IOT)
buildConfigField("String", "APP_TYPE", APP_TYPE_IOT)
applicationIdSuffix ".phone"
versionNameSuffix "-phone
}
}
组合多个产品风味(flavorDimensions)
某些情况下，您可能希望组合多个产品风味中的配置。
你应该经常有这种需求，要构建有启动图标和没有启动图标的两个APP，那么这个productFlavor和上文提到的productFlavors(car和phone)是两个维度的东西，那么我们创建两个维度的productFlavors，示例如下：
//两个维度：设备类型和图标类型
flavorDimensions "device_type", "icon_type"
productFlavors{
Car{
//指定该productFlavor是哪个维度
dimension 'device_type'
//根据不同的产品提添加不同的字段，以便在代码中进行判断
buildConfigField("String", "APP_LAUNCH_ACTIVITY", APP_LAUNCH_ACTIVITY_CAR)
buildConfigField("String", "APP_TYPE", APP_TYPE_CAR)
applicationIdSuffix ".car"
versionNameSuffix "-car
}
Phone{
dimension 'device_type'
buildConfigField("String", "APP_LAUNCH_ACTIVITY", APP_LAUNCH_ACTIVITY_IOT)
buildConfigField("String", "APP_TYPE", APP_TYPE_Phone)
applicationIdSuffix ".phone"
versionNameSuffix "-phone
}
with_icon{
dimension 'icon_type'
}
no_icon{
dimension 'icon_type'
}
}
选择变体
完成以上步骤后，点击Androidstudio左侧的Build Variant,可以看到如图所示的内容：
根据变体打包成不同的APP
根据上文选择的变体，点击工具栏中的Build APK可以生成对应的APP。
android.applicationVariants.all { variant ->
variant.outputs.all {
outputFileName = "${variant.name}-${variant.versionName}.apk"
}
}
buildAPK后可以生成如图的APP：
清单文件合并(AndroidManifest)
各个变体肯定需要差异化，不同的APPName、icon、或者是业务逻辑，要做到这些，需要先学习如何合并AndroidManifest。
首先建立对应的源集，默认的方式如图：
然后建立对应的AndroidManifest文件
合并优先级
可能你没有合并过AndroidManifest，但是肯定有这样的体验，以前我们使用jar包时需要在AndroidManifest中添加jar包中的组件和权限，但是在使用model或者远程依赖或者aar时就不需要添加，其实编译时就有合并的操作。
合并 3 个清单 文件（从优先级最低的文件（左）合并至优先级最高的文件（右））的流程：
那我们的变体是如何去合并的呢？
优先级如下（由高到低）（其实是定制程度高低决定）：
- 构建变体清单（如 src/demoDebug/）
- 构建类型清单（如 src/debug/）
- 产品定制清单（如 src/demo/）
合并冲突解决
内容较多，可以参考官方指南：https://developer.android.com/studio/build/manifest-merge.html#_3
官方文档介绍比较清楚了，这里不再重述。
构建差异
noIcon变种去掉启动图标
在对应noIcon的变种集下，AndroidManifest代码如下：
<activity
android:name=".view.activity.CarActivity"
android:configChanges="keyboard|screenSize|orientation"
android:launchMode="singleTask"
android:theme="@style/AppTheme.NoActionBar"
tools:node="merge">
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<category
android:name="android.intent.category.LAUNCHER"
tools:node="remove"/>
</intent-filter>
</activity>
即采用上文提到的 合并冲突解决 中的方式将启动LAUNCHER去掉。
不同变种启动的activity不同
可以将main中的启动activity去掉，在变体源集中将对应的activity添加进来，那么，按照合并优先级，变体源集中的activity会被合并进来。
不同的变体代码逻辑不同
可以看到上文 组合多个产品风味 中，有在产品风味中增加buildConfigField("String", "APP_TYPE", APP_TYPE_CAR)代码。
那么我们可以在代码中拿到这个标识，进行逻辑区分。
BuildConfig.APP_TYPE;
不同的代码和资源文件
在对应的源集下进行编码和存放资源文件即可，但是注意不要类路径和类名不要一样，不然会有冲突。
