使用gradle打包apk已經成為當前主流趨勢,我也在這個過程中經歷了各種需求,並不斷結合gradle新的支持,一一改進。在此,把這些相關的東西記錄,做一總結。
我想把其中的${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"]
}
}
}
對於簽名相關的信息,直接寫在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中讀取。
多渠道打包的關鍵之處在於,定義不同的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了。
前面說到默認的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版本同理。
上面我們在不同的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 是否保留調試信息
// ... ...
隨著產品渠道的鋪開,往往一套代碼需要支持多個產品形態,這就需要抽象出主要代碼到一個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即可實現全局統一配置。
默認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的文件夾下,清晰明了。
混淆能讓反編譯的代碼可讀性變的很差,而且還能顯著的減少APK包的大小。
相信很多朋友對混淆都覺得麻煩,甚至說,非常亂。因為添加混淆規則需要查詢官方說明文檔,甚至有的官方文檔還沒說明。當你引用了太多庫後,添加混淆規則將使一場噩夢。
這裡介紹一個技巧,不用查官方文檔,不用逐個庫考慮添加規則。
首先,除了默認的混淆配置(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.** { *; }
## ... ...
一般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也能定位到行了,為了這種解脫,這個代價我個人覺得是值的,而且超值!
假如想把當前的編譯時間、編譯的機器、最新的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, 有興趣可以過去一觀。
為了調試方便,我們往往會在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。
如何使用jenkins打包android和ios,並上傳到蒲公英平台,這個可以參考我的另外一篇文章專門介紹: 《使用Jenkins自動化構建Android和iOS應用》,不過,這篇文章還沒寫完,實際上在公司裡已經一直在用了,哪天心情好了總會寫完的,這裡不再贅述。
android打包因為groovy語言的強大,變的強大的同時必然也變的復雜,今天把我經歷的這些門道拿出來說道一下,做一個小小的總結,後續有更新我還會添加。
更多Android相關信息見Android 專題頁面 http://www.linuxidc.com/topicnews.aspx?tid=11