本文转自:http://www.jayfeng.com/2015/11/07/Android/

正文:

Android打包的那些事

发表于 2015-11-07 

使用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语言的强大，变的强大的同时必然也变的复杂，今天把我经历的这些门道拿出来说道一下，做一个小小的总结，后续有更新我还会添加。

使用gradle进行apk打包相关推荐

  1. python程序打包成apk_利用Gradle+Python3自动打包Android APK上传到蒲公英。

    利用Gradle+Python3自动打包Android APK上传到蒲公英. 面对每次都要打包一个版本发布给测试,都要手动打包签名~然后登录上传文件.这些繁琐的事情.于是就想到一句很经典的话,(人生苦 ...

  2. 【Android 安装包优化】动态库打包配置 ( “armeabi-v7a“, “arm64-v8a“, “x86“, “x86_64“ APK 打包 CPU 指令集配置 | NDK 完整配置参考 )

    文章目录 一.动态库打包配置 二.NDK 完整配置参考 三.参考资料 一.动态库打包配置 在 build.gradle 构建脚本中 , 配置 ndk 编译的动态库 CPU 架构类型 ; 在 " ...

  3. 【错误记录】Android Studio 导入外部 so 动态库报错 ( java.lang.UnsatisfiedLinkError | 指定 APK 打包动态库的 CPU 架构 )

    文章目录 一.报错信息 二.解决方案 ( 指定 APK 打包动态库的 CPU 架构 ) 一.报错信息 外部引用 so 动态库 , 如果只有一个 armeabi-v7a 的动态库 , 那么如果在 arm ...

  4. 如何手动完成一次APK打包？----APK编译全过程

    身为一个Android工程师,你是否有考虑过一个Android项目工程如何经过编译压缩变成一个APK的呢? 你又是否编写过打包工具完成多渠道打包呢? 下面我们来解密如何完成一个APK的打包. 1.使用 ...

  5. Android Studio下项目构建的Gradle配置及打包应用变体

    Gradle简介   Gradle是一个自动化构建工具,采用Groovy的Domain Specific Language(领域特定语言)来描述和控制构建逻辑.具有语法简洁.可读性强.配置灵活等特点. ...

  6. Eclipse + Gradle实现APK分包

    为什么80%的码农都做不了架构师?>>>    Eclipse + Gradle 实现APK分包 一.环境搭建 1.解压Gradle(gradle-2.2.1-all.zip)并配置 ...

  7. 【朝花夕拾】Android性能篇之（四）Apk打包

    前言 转载请声明,转自[https://www.cnblogs.com/andy-songwei/p/9721337.html],谢谢! APK,即Android Package,是将android程 ...

  8. 关于android3.0版本的apk打包安装失败的问题

    关于android3.0版本的apk打包安装失败的问题 最近遇到做项目遇到的一个坑,现在来总结一下,方便记录. 我用的as版本为3.0.1,直接连接电脑安装app是没有问题的,但是在签名打包apk以后 ...

  9. rn android mac打包,React-Native之MAC平台Android apk打包流程

    MAC :Android打包流程7步走:(详情参照英文官网) 1).使用keytool首先生成keystore(包含storeFile file.storePassword .keyAlias .ke ...

最新文章

  1. 由浅入深C A S，小白也能与BAT面试官对线
  2. aliyun tianchi ai contest meeting note
  3. hdu 527 Necklace
  4. Angular ActivatedRouteSnapshot
  5. asp.net读取xml方法
  6. skyline point解析
  7. pip install win32api报错解决方法
  8. 【原创】.NET Core应用类型（Portable apps Self-contained apps）
  9. 前端js获取本项目的项目根地址
  10. 苹果亮度自动调节怎么关闭_iPhone 总是自动亮屏，该怎么关闭？
  11. 区块链 以太坊 合约 创建、执行 详解
  12. H.264变换量化反量化反变换过程
  13. 迷你迅雷+SqlServer2008r2下载
  14. Android 圆角进度条
  15. 产品经理的5分钟统计课：产品/用户/数据平均情况是怎样？
  16. JetBrains DataGrip安装和使用的详细教程
  17. 【金猿技术展】基于数据控制三维组态的方法及装置——实现数据驱动三维模型的精准运转技术...
  18. 【日常学习】XML文件约束，Tomcat服务器和HTTP协议
  19. 国内外十大ERP软件系统排名！
  20. Java对接AD/LDAP的常见错误，以及解决办法

热门文章

  1. 什么前浪后浪，我们只不过是时代大潮中的一朵小浪花
  2. 2021-11-27 自定义接口挡板
  3. asterisk 使用php脚本socket通过AMI端口实现自动打电话报警
  4. 虫洞java_人类可穿越虫洞？物理学家新研究：虫洞旅行理论上并非不可能
  5. python数据预处理总结
  6. 变色龙app封装系统源码+完美版在售封装系统
  7. canvas生成随机（颜色位置）验证码
  8. 技术人的变现之路有哪些？
  9. RFID医疗资产管理解决方案-RFID电子标签-RFID固定资产管理-新导智能
  10. flink实现类似spark.yarn.jars的操作