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

最新推荐文章于 2022-03-18 15:52:22 发布

u011277123

最新推荐文章于 2022-03-18 15:52:22 发布

阅读量939

点赞数

科技优家 2016-09-19 11:39

参考：

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

需求可以总结如下：

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

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

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

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

android {

compileSdkVersion 24

buildToolsVersion "24.0.1"

//默认配置,所有 productFlavors 都会继承 defaultConfig 中配置的属性

defaultConfig {

//默认的 applicationId,一般与 AndroidManifest.xml 文件 package属性相同

applicationId "com.littlejie.multichannel"

minSdkVersion 15

targetSdkVersion 24

versionCode 1

versionName "1.0"

// productFlavors 定义了一个应用的自定义构建版本

//一个单一的项目可以同时定义多个不同的 flavor 来改变应用的输出。

// productFlavors 这个概念是为了解决不同的版本之间的差异非常小的情况，通常用于区分同一个应用的不同渠道/客户等，可包含少量业务功能差别。

// productFlavors 中的 flavor 不能跟 buildType 中的一样,否则会报: "ProductFlavor names cannot collide with BuildType names"

productFlavors {

//默认版本,不设置 applicationId ,继承 defaultConfig 中的配置

flavors_default {        }

//开发版本, applicationId 替换为 com.littlejie.multichannel.dev

flavors_dev {

applicationId "com.littlejie.multichannel.dev"

//发布版本, applicationId 替换为 com.littlejie.multichannel.dev

flavors_release {

applicationId "com.littlejie.multichannel.release"

MainActivity.java:

public class MainActivity extends Activity {

private static final String TAG = MainActivity.class.getSimpleName;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

Log.d(TAG, "package name = " + this.getPackageName);

在 Android Studio 中执行如下命令：

//打 debug 包，gradle 命令会在后面 `gradle task`中详细讲述gradle clean assembleDebug

打包完成后，将 Apk 安装到模拟器，运行，log 如下：

flavors_default:

09-17 22:43:55.390 19747-19747/com.littlejie.multichannel D/MainActivity: package name = com.littlejie.multichannel

flavors_dev:

09-17 22:11:30.860 2638-2638/com.littlejie.multichannel.dev D/MainActivity: package name = com.littlejie.multichannel.dev

flavors_release:

09-17 22:44:55.610 20650-20650/com.littlejie.multichannel.release D/MainActivity: package name = com.littlejie.multichannel.release

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

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

//输出 apk 的 AndroidManifest.xml 文件的信息aapt dump xmltree ***.apk AndroidManifest.xml

关于 aapt 使用的更多用法，可以阅读这篇博文：

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

lishengjiedeMacBook-Pro:apk littlejie$ aapt dump xmltree multichannel-flavors_dev-debug.apk AndroidManifest.xmlN: android=http://schemas.android.com/apk/res/android  E: manifest (line=2)    A: android:versionCode(0x0101021b)=(type 0x10)0x1    A: android:versionName(0x0101021c)="1.0" (Raw: "1.0")    //此处 package 的值已替换成 applicationId 的值    A: package="com.littlejie.multichannel.dev" (Raw: "com.littlejie.multichannel.dev")    A: platformBuildVersionCode=(type 0x10)0x18 (Raw: "24")    A: platformBuildVersionName=(type 0x4)0x40e00000 (Raw: "7.0")    E: uses-sdk (line=7)      A: android:minSdkVersion(0x0101020c)=(type 0x10)0xf      A: android:targetSdkVersion(0x01010270)=(type 0x10)0x18    E: application (line=11)      A: android:theme(0x01010000)=@0x7f08008e      A: android:label(0x01010001)=@0x7f060020      A: android:icon(0x01010002)=@0x7f030000      A: android:debuggable(0x0101000f)=(type 0x12)0xffffffff      A: android:allowBackup(0x01010280)=(type 0x12)0xffffffff      A: android:supportsRtl(0x010103af)=(type 0x12)0xffffffff      // Activity 的包名还是原来 Manifest.xml 中申明的      E: activity (line=17)        A: android:name(0x01010003)="com.littlejie.multichannel.MainActivity" (Raw: "com.littlejie.multichannel.MainActivity")        E: intent-filter (line=18) E: action (line=19) A: android:name(0x01010003)="android.intent.action.MAIN" (Raw: "android.intent.action.MAIN") E: category (line=21) A: android:name(0x01010003)="android.intent.category.LAUNCHER" (Raw: "android.intent.category.LAUNCHER")

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".

替换 AndroidManifest.xml 中的属性

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

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

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

productFlavors {

//将 AndroidManifest.xml 文件中的 ${UMENG_CHANNEL} 替换为 default

flavors_default {

manifestPlaceholders = [UMENG_CHANNEL: "defalut"]

flavors_dev {

applicationId "com.littlejie.multichannel.dev"

manifestPlaceholders = [UMENG_CHANNEL: "dev"]

flavors_release {

applicationId "com.littlejie.multichannel.release"

manifestPlaceholders = [UMENG_CHANNEL: "release"]

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

manifestPlaceholders = [VALUE_NAME1 : "value" , VALUE_NAME2 : "value"]

补充：关于 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 内容为：

<resources>

<string name="app_name">MultiChannel</string>

<string name="string_merge">我是string,我暂时没被合并</string>

</resources>

在 flavors_dev 下的 strings.xml 内容为：

<resources>

<string name="string_merge">我是dev_string,我会把string合并</string>

</resources>

当打 flavors_dev 渠道包时，最终 strings.xml 会变成：

<resources>

<string name="app_name">MultiChannel</string>

<string name="string_merge">我是dev_string,我会把string合并</string>

</resources>

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

多渠道使用独立签名

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

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

signingConfigs {

release {

storeFile file("签名文件路径")

storePassword "storePassword"

keyAlias "keyAlias"

keyPassword "keyPassword"

buildTypes {

release {

minifyEnabled true

proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

shrinkResources true

//指定打 release 包时使用的签名文件

signingConfig signingConfigs.release

//如果 debug 包需要测试诸如微信、地图等第三方 sdk ，则可以指定 debug 包使用 release 包的签名

//debug {

//    signingConfig signingConfigs.release

//}

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

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 的配置节选：

//定义签名属性

signingConfigs {

flavors_default {

//如果签名文件在项目的根目录下,则可以这么写

storeFile file("../littlejie.jks")       storePassword "******"       keyAlias "******"       keyPassword "*****"

flavors_dev {

storeFile file("../littlejie_dev.jks")       storePassword "*****"       keyAlias "*****"       keyPassword "*****"

buildTypes {

release {

minifyEnabled true

proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

shrinkResources true

//多个 flavor ,指定 flavor 使用指定 签名

productFlavors.flavors_default.signingConfig signingConfigs.flavors_default

productFlavors.flavors_dev.signingConfig signingConfigs.flavors_dev

//如果 debug 包需要测试诸如微信、地图等第三方 sdk ，则可以指定 debug 包使用 release 包的签名

//debug 并不能设置多个签名

//debug {

//   productFlavors.flavors_default.signingConfig signingConfigs.flavors_default

//   productFlavors.flavors_dev.signingConfig signingConfigs.flavors_dev

//}

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

//查看签名文件的属性keytool -list -keystore 签名文件//查看 apk 的签名，需要提前解压 apk ，获取 CERT.RSA（位于解压目录下 /META-INF 下）//以下命令行是在 apk 解压目录下执行keytool -printcert -file META-INF/CERT.RSA

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

首先，我们来看下 littlejie.jks 的信息：

lishengjiedeMacBook-Pro:AndroidDemo littlejie$ keytool -list -keystore littlejie.jks输入密钥库口令:密钥库类型: JKS密钥库提供方: SUN您的密钥库包含 1 个条目littlejie, 2016-9-18, PrivateKeyEntry,证书指纹 (SHA1): A2:B1:BF:BF:F1:F3:26:F4:FD:0C:94:95:B5:32:90:69:24:F7:99:84

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

lishengjiedeMacBook-Pro:apk littlejie$ keytool -printcert -file multichannel-flavors_default-release/META-INF/CERT.RSA所有者: CN=littlejie发布者: CN=littlejie序列号: 71693e05有效期开始日期: Sun Sep 18 17:20:34 CST 2016, 截止日期: Thu Sep 12 17:20:34 CST 2041证书指纹:     MD5: AC:12:83:51:44:FC:82:68:8B:23:7B:E9:12:24:AE:52     SHA1: A2:B1:BF:BF:F1:F3:26:F4:FD:0C:94:95:B5:32:90:69:24:F7:99:84     SHA256: AD:04:19:5F:92:00:0D:FA:7C:E5:8A:12:57:72:4C:1E:0E:2E:FC:0D:92:28:05:D0:CC:42:FC:93:95:44:88:88     签名算法名称: SHA256withRSA     版本: 3

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

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

//littlejie_dev.jks 的签名信息lishengjiedeMacBook-Pro:AndroidDemo littlejie$ keytool -list -keystore littlejie_dev.jks输入密钥库口令:密钥库类型: JKS密钥库提供方: SUN您的密钥库包含 1 个条目littlejie, 2016-9-18, PrivateKeyEntry,证书指纹 (SHA1): B4:25:67:A5:9F:8C:1F:12:BD:85:6B:2D:FE:71:62:57:8A:CC:AE:E2//multichannel-flavors_dev-release.apk 的签名信息lishengjiedeMacBook-Pro:apk littlejie$ keytool -printcert -file multichannel-flavors_dev-release/META-INF/CERT.RSA所有者: CN=littlejie发布者: CN=littlejie序列号: 48346e15有效期开始日期: Sun Sep 18 17:21:23 CST 2016, 截止日期: Thu Sep 12 17:21:23 CST 2041证书指纹:     MD5: 15:E9:E1:67:AB:33:8B:04:A4:C3:D0:05:8F:A6:35:37     SHA1: B4:25:67:A5:9F:8C:1F:12:BD:85:6B:2D:FE:71:62:57:8A:CC:AE:E2     SHA256: 96:A5:14:EC:28:25:32:0D:3E:D0:DB:D0:84:06:E7:9C:17:D7:91:83:A4:51:93:AB:34:3E:D9:FD:C5:FA:A1:8E     签名算法名称: SHA256withRSA     版本: 3

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

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

这里再做几点补充：

打全部包： 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，别的都还不错（吐槽产品）。

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

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

u011277123

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Gradle 实现 Android 多渠道定制化打包

科技优家 2016-09-19 11:39参考：最近在项目中遇到需要实现 Apk 多渠道、定制化打包， Google 、百度查找了一些资料，成功实现了上述功能，在此记录以备不时之需，温故而知新，可以为师矣~需求可以总结如下：如何实现多个 Apk 安装在同一设备在之前的印象中，同一个应用在同一设备上只能安装一个，除非手动修改 AndroidManifest.
复制链接

扫一扫