使用gradle打包apk已經成為當前主流趨勢，我也在這個過程中經歷了各種需求，并不斷結合gradle新的支持，一一改進。在此，把這些相關的東西記錄，做一總結。

1. 替換AndroidManifest中的占位符

我想把其中的${app_label}替換為@string/app_name

1 2 3 4 5

android{ defaultConfig{ manifestPlaceholders = [app_label:"@string/app_name"] } }

如果只想替換debug版本：

1 2 3 4 5 6 7 8 9

android{ buildTypes { debug { manifestPlaceholders = [app_label:"@string/app_name_debug"] } release { } } }

更多的需求是替換渠道編號：

1 2 3 4 5 6 7 8

android{ productFlavors { // 把dev產品型號的apk的AndroidManifest中的channel替換dev "dev"{ manifestPlaceholders = [channel:"dev"] } } }

2. 獨立配置簽名信息

對于簽名相關的信息,直接寫在gradle當然不好,特別是一些開源項目，可以添加到gradle.properties:

1 2 3 4

RELEASE_KEY_PASSWORD=xxxx RELEASE_KEY_ALIAS=xxx RELEASE_STORE_PASSWORD=xxx RELEASE_STORE_FILE=../.keystore/xxx.jks

然后在build.gradle中引用即可：

1 2 3 4 5 6 7 8 9 10

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標識：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

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了:

1 2 3 4 5 6 7 8 9 10

devDebug devRelease officialDebug officialRelease wandoujiaDebug wandoujiaRelease xiaomiDebug xiaomiRelease 360Debug 360Release

其中debug, release是gradle默認自帶的兩個build type, 下一節還會繼續說明。
選擇一個，就能編譯出對應渠道的apk了。

4. 自定義Build Type

前面說到默認的build type有兩種debug和release，區別如下：

1 2 3 4 5 6 7 8 9 10

// 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版本一樣，但是要保留debug狀態（如果做過rom開發的話，類似于user debug版本），我們稱為preview版本吧。
其實很簡單：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

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的版本。
除此之外，可能還可以配置一些參數，我這里列幾個我在工作中用到的：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

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' } } }

這些都用的太多了，稍微解釋一下：

1 2 3 4 5 6 7

// minifyEnabled 混淆處理 // shrinkResources 去除無用資源 // signingConfig 簽名 // proguardFiles 混淆配置 // applicationIdSuffix 增加APP ID的后綴 // debuggable 是否保留調試信息 // ... ...

6. 多工程全局配置

隨著產品渠道的鋪開，往往一套代碼需要支持多個產品形態，這就需要抽象出主要代碼到一個Library，然后基于Library擴展幾個App Module。
相信每個module的build.gradle都會有這個代碼：

1 2 3 4 5 6 7 8 9 10 11

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全局變量:

1 2 3 4 5 6 7 8

ext { compileSdkVersion = 22 buildToolsVersion = "23.0.1" minSdkVersion = 10 targetSdkVersion = 22 versionCode = 34 versionName = "v2.6.1" }

然后在各module的build.gradle中引用如下：

1 2 3 4 5 6 7 8 9 10 11 12

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個渠道包的時候，就麻煩了，不知道誰是誰了。
這個時候，就需要自定義導出的APK名稱了，不同的渠道編出的APK的文件名應該是不一樣的。

1 2 3 4 5 6 7 8 9 10

android { // rename the apk with the version name applicationVariants.all { variant -> variant.outputs.each { output -> output.outputFile = new File( output.outputFile.parent, "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase()) } } }

當apk太多時，如果能把apk按debug，release，preview分一下類就更好了（事實上，對于我這樣經常發版的人，一編往往就要編四五十個版本的人，debug和release版本全混在一起沒法看，必須分類），簡單：

1 2 3 4 5 6 7 8 9 10 11

android { // rename the apk with the version name // add output file sub folder by build type applicationVariants.all { variant -> variant.outputs.each { output -> output.outputFile = new File( output.outputFile.parent + "/${variant.buildType.name}", "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase()) } } }

現在生成了類似于ganchai-dev-preview-v2.4.0.0.apk這樣格式的包了，preview的包自然就放在preview的文件夾下，清晰明了。

8. 混淆技巧

混淆能讓反編譯的代碼可讀性變的很差，而且還能顯著的減少APK包的大小。

1). 第一個技巧

相信很多朋友對混淆都覺得麻煩，甚至說，非常亂。因為添加混淆規則需要查詢官方說明文檔，甚至有的官方文檔還沒說明。當你引用了太多庫后，添加混淆規則將使一場噩夢。
這里介紹一個技巧，不用查官方文檔，不用逐個庫考慮添加規則。
首先，除了默認的混淆配置(android-sdk/tools/proguard/proguard-android.txt), 自己的代碼肯定是要自己配置的：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

## 位于module下的proguard-rules.pro ##################################### ######### 主程序不能混淆的代碼 ######### ##################################### -dontwarn xxx.model.** -keep class xxx.model.** { *; } ## 等等，自己的代碼自己清楚 ##################################### ########### 不優化泛型和反射 ########## ##################################### -keepattributes Signature

接下來是麻煩的第三方庫，一般來說，如果是極光推的話，它的包名是cn.jpush, 添加如下代碼即可：

1 2	-dontwarn cn.jpush.** -keep class cn.jpush.** { *; }

其他的第三庫也是如此，一個一個添加，太累！其實可以用第三方反編譯工具（比如jadx：https://github.com/skylot/jadx?），打開apk后，一眼就能看到引用的所有第三方庫的包名，把所有不想混淆或者不確定能不能混淆的，直接都添加又有何不可：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

##################################### ######### 第三方庫或者jar包 ########### ##################################### -dontwarn cn.jpush.** -keep class cn.jpush.** { *; } -dontwarn com.squareup.** -keep class com.squareup.** { *; } -dontwarn com.octo.** -keep class com.octo.** { *; } -dontwarn de.** -keep class de.** { *; } -dontwarn javax.** -keep class javax.** { *; } -dontwarn org.** -keep class org.** { *; } -dontwarn u.aly.** -keep class u.aly.** { *; } -dontwarn uk.** -keep class uk.** { *; } -dontwarn com.baidu.** -keep class com.baidu.** { *; } -dontwarn com.facebook.** -keep class com.facebook.** { *; } -dontwarn com.google.** -keep class com.google.** { *; } ## ... ...

2). 第二個技巧

一般release版本混淆之后，像友盟這樣的統計系統如果有崩潰異常，會記錄如下：

1 2	java.lang.NullPointerException: java.lang.NullPointerException at com.xxx.TabMessageFragment$7.run(Unknown Source)

這個Unknown Source是很要命的，排除錯誤無法定位到具體行了，大大降低調試效率。
當然，友盟支持上傳Mapping文件，可幫助定位，mapping文件的位置在：

1 2	project > module > build > outputs > {flavor name} > {build type} > mapping.txt

如果版本一多，mapping.txt每次都要重新生成，還要上傳，終歸還是麻煩。
其實，在proguard-rules.pro中添加如下代碼即可：

1	-keepattributes SourceFile,LineNumberTable

當然apk包會大那么一點點（我這里6M的包，大個200k吧），但是再也不用mapping.txt也能定位到行了，為了這種解脫，這個代價我個人覺得是值的，而且超值！

9. 動態設置一些額外信息

假如想把當前的編譯時間、編譯的機器、最新的commit版本添加到apk，而這些信息又不好寫在代碼里，強大的gradle給了我創造可能的自信：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

android { defaultConfig { resValue "string", "build_time", buildTime() resValue "string", "build_host", hostName() resValue "string", "build_revision", revision() } } def buildTime() { return new Date().format("yyyy-MM-dd HH:mm:ss") } def hostName() { return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName } def revision() { def code = new ByteArrayOutputStream() exec { commandLine 'git', 'rev-parse', '--short', 'HEAD' standardOutput = code } return code.toString() }

上述代碼實現了動態的添加了3個字符串資源: build_time、build_host、build_revision, 然后在其他地方可像如引用字符串一樣使用如下：

1 2 3 4

// 在Activity里調用 getString(R.string.build_time) // 輸出2015-11-07 17:01 getString(R.string.build_host) // 輸出jay@deepin，這是我的電腦的用戶名和PC名 getString(R.string.build_revision) // 輸出3dd5823, 這是最后一次commit的sha值

這個地方，如何從命令行讀取返回結果，很有意思。
其實這段代碼來自我學習VLC源碼時偶然看到，深受啟發，不敢獨享，特摘抄在此。
vlc源碼及編譯地址：https://wiki.videolan.org/AndroidCompile，?有興趣可以過去一觀。

10. 給自己留個”后門”: 點七下

為了調試方便，我們往往會在debug版本留一個顯示我們想看的界面（記得之前微博的一個iOS版本就泄露了一個調試界面），如何進入到一個界面，我們可以仿照android開發者選項的方式，點七下才顯示，我們來實現一個：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

private int clickCount = 0; private long clickTime = 0; sevenClickView.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { if (clickTime == 0) { clickTime = System.currentTimeMillis(); } if (System.currentTimeMillis() - clickTime > 500) { clickCount = 0; } else { clickCount++; } clickTime = System.currentTimeMillis(); if (clickCount > 6) { // 點七下條件達到，跳到debug界面 } } });

release版本肯定是不能暴露這個界面的，也不能讓人用am在命令行調起，如何防止呢，可以在release版本把這個debug界面的exported設為false。

11. 自動化構建

如何使用jenkins打包android和ios，并上傳到蒲公英平臺，這個可以參考我的另外一篇文章專門介紹:《使用jenkins自動化構建android和ios應用》，不過，這篇文章還沒寫完，實際上在公司里已經一直在用了，哪天心情好了總會寫完的，這里不再贅述。

12. 小結

android打包因為groovy語言的強大，變的強大的同時必然也變的復雜，今天把我經歷的這些門道拿出來說道一下，做一個小小的總結，后續有更新我還會添加。

原文地址： http://jayfeng.com/2015/11/07/Android%E6%89%93%E5%8C%85%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B/

總結

以上是生活随笔為你收集整理的Android打包的那些事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。