有時候咱們一個app須要有不一樣的版本,不一樣的版本又會使用不一樣的配置,咱們可使用gradle進行管理。java
1、構建版本Build types:android
常見的構建版本有debug與release。
app
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以下:gradle
也能夠採用繼承的方式:ui
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的配置。spa
在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 }
以後咱們能夠看到:debug
注意若是要添加的是String,那麼雙一號裏面須要再一個雙引號標識字符串"\"custom app\"",斜杆是對裏面雙引號進行轉義。code
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極大簡化了基於相同的代碼構建不一樣版本的app。
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
構建變體
構建變體是構建版本和生產版本的結合體。當你建立了一個構建版本或者生產版本,一樣的,新的變體也會被建立。
像咱們上圖便有這麼多的變體:
咱們能夠在這個窗口進行切換,而後運行不一樣的變體。
assembleDebug
一個是assembleRelease
來構建不一樣的APK。當添加一個新的Build Type的時候,一個新的Task也就會被建立,一旦你開始添加Flavors,一整套Tasks就會被建立,由於每個BuildType的Tasks都會爲每一個Product Flavor聯合。
構建變體也能夠有本身的資源文件夾,舉個例子,你能夠有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。