鏈接：
https://www.cnblogs.com/tangZH/p/10999060.html
有時候我們一個app需要有不同的版本，不同的版本又會使用不同的配置，我們可以使用gradle進行管理。
- Build types
- Product flavors
- Build variants
- Signing configurations
一、構建版本Build types：
常見的構建版本有debug與release。
buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } }
自定義構建版本：
custom { applicationIdSuffix ".custom"
versionNameSuffix ".custom"
minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.readerDaquanConfig }
除了debug構建版本不需要簽名外，其它的都是需要配置簽名的，不然無法運行在手機上，該版本定義了新的applicationId與版本號。不同構建版本的applicationId如下：
- Debug: com.package
- Release: com.package
- Staging: com.package.staging
也可以采用繼承的方式：
custom.initWith(buildTypes.debug) custom { applicationIdSuffix ".custom" versionNameSuffix ".custom" minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.readerDaquanConfig }
custom繼承debug構建版本的配置，custom中的配置會覆蓋debug的配置。
在BuildConfig中添加變量
custom { applicationIdSuffix ".custom" versionNameSuffix ".custom" buildConfigField("String", "name","\"custom app\"") buildConfigField("int", "id", "0") minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.readerDaquanConfig }
之后我們可以看到：
注意如果要添加的是String，那么雙一號里面需要再一個雙引號標識字符串"\"custom app\""，斜桿是對里面雙引號進行轉義。
Source sets
source set。默認的source set目錄會放在相同的Build Type的目錄下。當你創建一個新的build type時，該目錄不會自動創建，你必須在你使用代碼與資源前自己為每一個build type創建source set目錄。
app └── src ├── debug │ ├── java │ │ └── com.package │ ├── res │ │ └── layout │ │ └── activity_main.xml │ └── AndroidManifest.xml ├── main │ ├── java │ │ └── com.package │ ├── res └── MainActivity.java └── Constants.java │ └── AndroidManifest.xml ├── custom │ ├── java │ │ └── com.package ├── drawable └── layout └── activity_main.xml │ ├── res │ │ └── layout │ │ └── activity_main.xml │ └── AndroidManifest.xml └── release ├── java │ └── com.package │ └── Constants.java └── AndroidManifest.xml
假如我們自己建立custom的source set
我們使用不同的構建版本便會使用不同的source set。當使用不同的source sets的時候，資源文件的處理需要特殊的方式。Drawables和layout文件將會復寫在main中的重名文件，但是values文件下的資源不會。gradle將會把這些資源連同main里面的資源一起合並。（如果出現資源重復異常，請clean一下工程）
例如，在main中的string.xml為：
<resources>
<string name="app_name">BuildTypeProject</string>
<string name="hello_name">BuildTypeHello</string>
</resources>
在custom版本中為：
<resources>
<string name="app_name">BuildTypeCustomProject</string>
</resources>
當我們構建custom版本的時會合並為：
<resources>
<string name="app_name">BuildTypeCustomProject</string>
<string name="hello_name">BuildTypeHello</string>
</resources>
當你創建一個新的構建版本而不是custom，最終的strings.xml將會是main目錄下的strings.xml。
manifest也和value文件下的文件一樣。如果你為你的構建版本創建了一個manifest文件，那么你不必要去拷貝在main文件下的manifest文件，你需要做的是添加標簽。Android插件將會為你合並它們。
但是需要注意，當我們添加.java文件到custom版本中，你可以添加相同的類到debug和release版本，但是不能添加到main版本。如果你添加了，會拋出異常。這時候我們如果構建custom版本，那么便會使用custom對應source set中的.java文件。
依賴包
每一個構建版本都有自己的依賴包，gradle自動為每一個構建的版本創建不同的依賴配置。如果你想為debug版本添加一個logging框架，你可以這么做：
dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:22.2.0' debugCompile 'de.mindpipe.android:android-logging-log4j:1.0.3' }
product flavors
不同的生產版本。
product flavors極大簡化了基於相同的代碼構建不同版本的app。
創建product flavors
android { productFlavors { vivo { applicationId "vivo" versionCode 1 minSdkVersion 15 } oppo { applicationId "oppo" versionCode 2 minSdkVersion 15 } } }
這時候AS 3.0以上會報錯ERROR: All flavors must now belong to a named flavor dimension
沒有給它們設置一個風味維度，我們可以加上
flavorDimensions "default"
flavorDimensions "default" android { productFlavors { vivo { applicationId "vivo" versionCode 1 minSdkVersion 15 } oppo { applicationId "oppo" versionCode 2 minSdkVersion 15 } } }
給這些產品版本默認一個風味維度，具體有何作用，等會會講。
這時候我們會在左下角的窗口看到這么多個變體：
如果找不到該窗口，可以在這里打開：
由於我們之前在custom構建版本上設置了applicationIdSuffix ".custom"，所以，當我們運行oppoCustom版本的時候，applicationId為oppo.custom
Source Set
product Flavors也有自己的代碼文件夾。創建一個特殊的版本就像創建一個文件夾那么簡單。如下圖所示：
但是值得注意的是，我們無法再vivo文件夾里相同的包中添加構建版本已經有的.java文件，添加了會報異常。而對於資源文件，我們可以添加構建版本里面有的文件，但是這個產品版本所對應的目錄的優先級低於Build type，也就是說，當Custom目錄有一張圖片，vivo目錄也有一張圖片，那么當我們運行打包vivoCustom版本的時候，使用的是custom里面的圖片。除非我們建立的文件夾是vivoCustom，那么它的優先級便會是最高的。
Multiflavor variants
在某些情況下，你可能希望創建一些聯合的Product Flavors，這個時候便要使用到我們剛剛所說的flavorDimensions 了。
設想一下，假如我們需要打包兩個渠道的app：vivo和oppo，而這兩個渠道的app各自有付費版與免費版，那么我們就需要用到多維度了。
首先定義兩個維度：渠道channel，付費與免費：money
flavorDimensions "channel","money"
flavorDimensions "channel","money" android { productFlavors { vivo { dimension "channel" applicationId "vivo" versionCode 1 minSdkVersion 15 } oppo { dimension "channel" applicationId "oppo" versionCode 2 minSdkVersion 15 } free { dimension "money" } vip { dimension "money" } } }
當你添加了flavor dimensions，你就需要為每個flavor添加dimension，否則會提示錯誤。
之后我們可以看到這么多個變體：
而我們定義多個維度的順序是很重要的，因為當你在各個維度各自定義了同一個常量的值，比如：buildConfigField("String", "name","\"custom app\"")，總是以第一維度的為准。
Build variants
構建變體
構建變體是構建版本和生產版本的結合體。當你創建了一個構建版本或者生產版本，同樣的，新的變體也會被創建。
像我們上圖便有這么多的變體：
我們可以在這個窗口進行切換，然后運行不同的變體。
tasks
assembleDebug一個是assembleRelease來構建不同的APK。當添加一個新的Build Type的時候，一個新的Task也就會被創建，一旦你開始添加Flavors，一整套Tasks就會被創建，因為每一個BuildType的Tasks都會為每個Product Flavor聯合。
Source sets
構建變體也可以有自己的資源文件夾，舉個例子，你可以有src/vivoVipCustom/java/。原理與上面的類似
Resource and mainfest merging
Android Plugin需要在打包前對Main的SourceSet以及BuildType的SourceSet進行一次Merge。而且Library工程也會提供額外的資源，它們也會被Merge，例如Manifest.xml等等。也會在其中聲明一些權限等。
Resource和Manifest.xml的優先級順序如下：
如果一個資源在main中和在flavor中定義了，那么那個在flavor中的資源有更高的優先級。這樣那個在flavor文件夾中的資源將會被打包到apk。而在依賴項目申明的資源總是擁有最低優先級。
當然，如果你建立的目錄是變體的目錄入：vivoVipCustom，那么它的優先級自然是高於Build type
創建構建變體
關於如何構建變量，上面已經說了，不再重復。
flavorDimensions "channel","money" android { productFlavors { vivo { dimension "channel" applicationId "vivo" versionCode 1 minSdkVersion 15 } oppo { dimension "channel" applicationId "oppo" versionCode 2 minSdkVersion 15 } free { dimension "money" resValue "color", "colorfree", "#ff8888" } vip { dimension "money" resValue "color", "colorfree", "#ff0000" } } }
resValue "color", "colorfree", "#ff8888"表示添加顏色名為colorfree的顏色
變體過濾器
忽略某個變體也是可行的。這樣你可以加速你的構建當使用assemble的時候，這樣你列出的tasks將不會執行那么你不需要的變體。你可以使用過濾器，在build.gradle中添加代碼如下所示：
android.variantFilter { variant ->
if(variant.buildType.name.equals('release')) { variant.getFlavors().each() { flavor ->
if (flavor.name.equals('vivo')) { variant.setIgnore(true); } } } }
發現相關的變體不見了：
Signing Configurations
在你發布你的應用之前，你需要為你的app私鑰簽名。如果你有付費版和免費版，你需要有不同的key去簽名不同的變體。這就是配置簽名的好處。配置簽名可以這樣定義：
android { signingConfigs { custom.initWith(signingConfigs.debug) release { storeFile file("release.keystore") storePassword"secretpassword" keyAlias "gradleforandroid" keyPassword "secretpassword" } } }
在這個例子中，我們創建了2個不同的簽名配置。debug配置是as默認的，其使用了公共的keystore和password，所以沒有必要為debug版本創建簽名配置了。custom配置使用了initWith()方法，其會復制其他的簽名配置。這意味着custom和debug的key是一樣的。
release配置使用了storeFile，定義了key alias和密碼。當然這不是一個好的選擇，你需要在 Gradle properties文件中配置。
當你定義了簽名配置后，你需要應用它們。構建版本都有一個屬性叫做signingConfig，你可以這么干：
android {
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}
上例使用了buildTypes，但是你可能需要對每個版本生成不同的驗證，你可以這么定義：
android {
productFlavors {
vivo{
signingConfig signingConfigs.release
}
}
}
當簽名一個Flavor版本的時候，你需要重寫BuildType中的簽名配置。當需要使用相同的BuildType不同版本的Flavors的簽名時，可以通過下述方式：
android {
buildTypes {
release {
productFlavors.vivo.signingConfig signingConfigs.vivo
productFlavors.oppo.signingConfig signingConfigs.oppo
}
}
}
上面這個例子展示了如何在vivo和oppo的Release版本使用不同的簽名，但是卻不影響Debug和Custom的BuildType。