Gradle 实现 Android 多渠道定制化打包

最近在项目中遇到需要实现 Apk 多渠道、定制化打包, 查找了一些资料,成功实现了上述功能,在此记录以备不时之需,温故而知新,可以为师矣~

需求可以总结如下:
多渠道打包

如何实现多个 Apk 安装在同一设备

在之前的印象中,同一个应用在同一设备上只能安装一个,除非手动修改 AndroidManifest.xml 文件中的包名( package ),但这么做的后果就是新的应用真的是新的应用,旧版应用再也收不到更新。而现在你通过 Gradle,你可以轻松构建多个不同版本的应用,并且在同一设备上安装使用。

这里要用到 productFlavors ,productFlavors 可以用来自定义应用构建版本,我们可以用其 applicationId 属性来实现多个 Apk 安装在同一设备上。

build.gradle 中部分配置代码如下:

MainActivity.java:

在 Android Studio 中执行如下命令:

打包完成后,将 Apk 安装到模拟器(adb install name.apk),运行,log 如下:

flavors_default:

flavors_dev:

flavors_release:

从这里可以看出,不同 flavor 的 package name 被 applicationId 替换掉了,而且同一个模拟器上可以同时安装以上三个应用。

下面我们再看看 AndroidManifest.xml 中发生了什么变化。这里需要用到 aapt 来查看 AndroidManifest.xml 的信息:

关于 aapt 使用的更多用法,可以阅读这篇博文:使用 aapt 查看 apk 的各种信息

下面是 flavors_dev 版本的信息,可以看出 Java 源文件的包名并没有发生改变,而 package 属性的值被替换为 applicationId了。

applicationId 的原理可以理解为在 gradle 打包的时,动态合并属性,将 package 替换为 applicationId 指定的值,但并不会替换 Java 文件的包名,包括生成的 R 文件(可以去对应 module 下的 build/generated 目录下查看对应 flavor 的 R 文件)。

Android 官方文档原文如下:

Therefore, we have decoupled the two usages of package name:

The final package that is used in your built .apk’s manifest, and is the package your app is known as on your device and in the Google Play store, is the “application id”.

The package that is used in your source code to refer to your R class, and to resolve any relative activity/service registrations, continues to be called the “package”.

补充ApplicationId versus PackageName

替换 AndroidManifest.xml 中的属性

这里可以参考友盟统计 SDK 中使用的方案。该方案通过在 AndroidManifest.xml 文件中 application 标签下指定 <mate-data>  设置占位符来实现动态替换属性值。

占位符形如${name},在最终执行 AndroidManifest.xml 文件合并的时候,占位符会被 build.gradle 中对应值取代。 build.gradle 的配置需要用到上节讲到的 productFlavors 的 manifestPlaceholders 属性, manifestPlaceholders 属性直译过来就是清单文件占位符

下面是 build.gradle 的节选代码:

如果你要替换多个属性,则只需要将 manifestPlaceholders 的写法如下:

补充:关于 AndroidManifest 文件合并规则可以查看 官方文档

替换资源文件

多渠道打包的时候可能会碰到这种情况:每个应用市场的启动页图标、应用名称可能会有点小出入,更有甚者,连布局都不一样。这时候我们该怎么办呢?

有一种解决办法就是:在代码里进行判断,根据渠道的不一样,加载不同的图片和布局,这是一种解决办法。但是当渠道有很多时,代码就会变得很难维护,而且指定渠道用到的资源文件都会被打入所有 Apk 中。所以这个方法并不值得推荐。那么,有什么好的解决办法呢?

办法 Google 早就给我们想好了,而且相当简单,那就是:在 main 的同级目录下创建以渠道名命名的文件夹,然后创建资源文件(路径要与 main 中的一致),然后打包的时候 gradle 就会自己替换或者合并资源。

例如, App 的默认 icon 路径为 main\res\mipmap-hdpi\ic_launcher.png ,那么 flavors_dev的路径就为 flavors_dev\res\mipmap-hdpi\ic_launcher.png ,打包 flavors_dev 渠道的时候会自动替换图片。

对于资源合并,如果在 main 下的 strings.xml 内容为:

在 flavors_dev 下的 strings.xml 内容为:

当打 flavors_dev 渠道包时,最终 strings.xml 会变成:

以上特性可以用来替换 Apk 的应用名称和应用图标,这比使用前面讲到的占位符方便很多。同理,替换图片和合并颜色的原理也相似。

多渠道使用独立签名

多渠道打包的时候,可能每个渠道包的签名都必须不一样,真正做到定制化,那么,怎么实现每个渠道包使用指定的签名呢?

平时我们打包的时候是这样的:

而给每个渠道包指定签名其实也差不多。

Google 官方原话:

This enables either having all release packages share the same SigningConfig, by setting android.buildTypes.release.signingConfig, or have each release package use their own SigningConfig by setting each android.productFlavors.*.signingConfig objects separately.

大意就是,在 buildType 下指定签名的具体属性,形如 android.productFlavors.*.signingConfig signingConfigs.* ,前一个 * 指代在 productFlavors 中定义的 flavor ,后一个 * 指代在 signingConfigs 定义的属性。值得注意的是,signingConfigs 必须定义在 buildType 之前。

以下是 build.gradle 的配置节选:

下面我们来验证下生成的包的签名是否正确,查看签名我们会用到如下两个命令:

更多 keytool 命令使用可以查看 官方文档

首先,我们来看下 littlejie.jks 的信息:

解压 multichannel-flavors_default-release.apk ,查看 CERT.RSA 信息

可以发现两者的 SHA1 值是相等的。

同理,可以查看 littlejie_dev.jks 和 multichannel-flavors_dev-release.apk 的签名信息

但是这里有个问题,就是这种给某个 flavor 指定签名的方法对 debug 无效,有兴趣的同学可以看上述注释掉的 debug 签名部分配置。简单来说,debug 签名只能指定一个或者使用默认的 debug 签名。

若哪位大神有解决方案,欢迎指出~

这里再做几点补充:

  1. 多渠道使用独立签名,打包时千万不要使用 Android Studio 中 Build 菜单下的 Generate Signed APK,因为当你使用这个打包的时候, Android Studio 会让你指定使用的签名文件, so 你就等着哭吧~楼主因为这个折腾了半天。解决方法就是使用 gradle tasks。传送门:Android Gradle Build Tasks
  2. 鉴于第一点中的传送门需要FQ,所以在这里简单介绍一下 Android Gradle Build Tasks 的使用。
  • 打全部包: gradle assemble
  • 打全部 Debug 包: gradle assembleDebug ,可以简写为 gradle aD ,前提是没有相同缩写的参数
  • 打全部 Release 包: gradle assembleRelease,可以简写为 gradle aR
  • 打指定 flavor 包: gradle assemble(flavor)(Debug|Release)
  • 打包完成后安装(设备上没有安装该 apk ,否则会失败,而且只能指定 flavor ,不然也会失败): gradle install(flavor)(Debug|Release)
  • 打包前先 clean 一下(在测试的时候很必要,如果不 clean 的话,可能会导致某些小修改不会及时打入新包): gradle clean assembleDebug

利用 Gradle 修改构建版本号

楼主表示对 Groovy 不是很熟,所以利用 Gradle 自动修改构建版本这个就先留着,我先去研究几天~

总结

以上就是自己在使用 Gradle 实现 Android 多渠道打包时碰到的问题, Android 官方关于使用 Gradle 的文档已经很详细了,自己总结的只是一点皮毛,有时间要去自习研读下。

工作一年多,愣是没有写博客做总结,好多东西都是用过就忘,下次要用再找,没有成体系的 Android 知识结构,对工资不满意,可就连想跳槽面试都没底气。这次写这篇博客画了思维导图,自以为逻辑清晰了,可是真正要把这些东西讲述清楚,还真是一件麻烦的事~看来,自己还有很长的路要走~

这段时间自己也在思考,是转行还是去考事业编制,还是继续做 Android。转行,除了编程自己好像别的什么也不会,当然自己编程也做的不怎么好。考事业编制,这个可以考虑,毕竟再很多人眼里这是个旱涝保收的职业。继续做 Android ,这个也不错,除了每次都花大把时间用来改 UI,别的都还不错(吐槽产品)。

话说,有没有什么工作,自由、上班时间少、工资高的?当然没有,至少现阶段的自己是接触不到的,所以,骚年,还是努力吧!多读书、多看报、多运动,少吃零食多睡觉~

恩,算是对工作一年多的总结也是吐槽~

读万卷书,行万里路~

参考

  1. Gradle Plugin User Guide
  2. Android Plugin DSL Reference
  3. Android Studio Gradle实践之多渠道自动化打包+版本号管理

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

任选一种支付方式

4 7 收藏 4 评论

关于作者:踏歌行

希望有一天我能够很坦然地说:\"让我来告诉你,在我眼中,这是一个怎样的世界。\" 个人主页 · 我的文章 · 24 ·   

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 上杉   2016/09/20

    楼主也认为考事业编制比程序员好吗?

    • 踏歌行 程序猿 2016/09/20

      相对而言,事业编制压力小点,而且像楼主这种水平的,事业编制和程序员待遇可能还是事业编制好点,心酸~

  • 流放   2016/09/26

    lz怎么在Terminal下使用gradle命令?我使用他”不是内部或外部命令,也不是可运行的程序 或批处理文件”。 配置环境变量的时候,多个项目可能使用的gradle版本不一样,这个应该怎么配?

    • 踏歌行 程序猿 2016/09/26

      配置下环境变量就好了。多个项目使用不同gradle版本这个问题我也没碰到过,爱莫能助~

跳到底部
返回顶部