Android 多渠道快速打包构建

一、什么是Android 渠道包

Android渠道包是指在向各大应用市场发布APK包时，针对不同渠道所进行的区分，区分的方式有很多种，有常用的方式在AndroidManifest的meta-data的某个标签下配置key-value值；有在APK的压缩包 META-INF目录下添加一个空文件，通过问件名对渠道进行标识；或者在利用APK文件是zip文件的特性，对zip的comment信息进行修改；还有对APK文件的ZIP 信息EOCD中的签名块信息进行修改。Android渠道包存在的意义是为了方便统计不同渠道下的APP下载安装量，以此来更好的掌握用户的操作习惯。

二、多渠道包的构建

2.1 传统的gradle-packer-plugin方式

这种方式的做法可参考如下，在APP的build.gralde中定义需要打包的渠道

productFlavors{ "YingYongBao" { manifestPlaceholders = [InstallChannel : "YingYongBao" ] } "360" { manifestPlaceholders = [InstallChannel : "360" ] } }

在AndroidManifest.xml中添加meta-data

<meta-data android:name= "InstallChannel" android:value=" ${InstallChannel}" />

在APP的启动过程中，添加代码，将渠道发送给统计平台，下面代码中采用了友盟统计

public static void init (Context context) { String channel = getChannelName(context); UMConfigure.init(context, "***********************" , channel, UMConfigure.DEVICE_TYPE_PHONE, null ); } private static String getChannelName (Context context) { try { ApplicationInfo appInfo = context.getPackageManager().getApplicationInfo(context.getPackageName(), PackageManager.GET_META_DATA); Bundle bundle = appInfo.metaData; return bundle. getString ( "InstallChannel" ); } catch (PackageManager.NameNotFoundException e) { //can never happen } return "" ; }

在完成上述代码布置之后，就是采用命令 ./gradlew clean assembleRelease对定义的渠道编译打包。

传统方式的优缺点：

优点：就是可以通过productlavors保存不同渠道的差异性，对每一个渠道都会重新进行编译打包。

缺点：在只存在渠道名差异的情况下，对每一个渠道都重新进行编译，非常耗时。以个人电脑统计，40个渠道包编译下来会花费35分钟左右，另外还容易出现虚拟机内存不够的错误。

2.2 多渠道快速打包构建

多渠道快速打包需要涉及到Android的签名校验机制V1 方案和V2方案，关于这两个方案简单介绍如下。

方案V1：针对APK中的每个原始文件的完整性进行签名计算，最后在META-INF目录下生成MANIFEST.MF、CERT.SF和CERT.RSA三个文件，APK在解压安装时通过他们来校验APK的内容是否有被修改。

方案V2：对整个APK的完整性进行校验(不包含签名块本身)，V2是Android 7.0之后针对APK的安全性引入的升级版。

APK在发布过程中，如果只使用V1签名，APK在所有手机上的安装并不会有影响，只是没能很好的利用Android7.0以上版本的安全性。如果只采用V2签名机制，发布的APK则在Android7.0以下的手机无法进行安装。因此最优的方式是让APK在发布时签名同时支持V1和V2两种方案的签名。但是这样问题就来了，V2签名方案对原有支持V1签名的多渠道打包方案使用带来了限制，因为V2是对APK的整包进行签名，限制了对APK文件的修改，而很多支持V1签名的多渠道打包方案在APK文件签名之后的再次修改APK文件时都会破坏V2签名校验APK的完整性。

因此下面将会从支持V1和V2签名来对多渠道打包方案进行分类和说明：

2.2.1 只支持V1签名的打包方案

只支持V1签名的打包方案并不是本博客所介绍的重点，因此下面只是对他们进行一个列举总结，具体使用方式可以进一步参考链接和百度搜索

多渠道打包方案	packer-ng-plugin(V2版本之前)	meituan早期版本
采取的方案	对Android的APK文件的ZIP包填写comment信息	在APK文件的META-INF文件夹中添加一个空的文件，以名字来命名渠道信息
参考链接	https://www.douban.com/note/578374148/	https://blog.csdn.net/cdecde111/article/details/55506311

2.2.2 支持V2签名方案

支持V2签名方案的多渠道打包都是针对APK文件ZIP信息中的EOCD块中的签名块信息中的ID-Value Pair进行修改，V2签名对签名块不会进行校验，关于支持V2签名方案的技术实现细节可以参考如下两份博客

https://www.cnblogs.com/qcloud1001/p/6758233.html

https://tech.meituan.com/android-apk-v2-signature-scheme.html （该博客是美团方案提供者的研究总结）

支持V2签名方案存在如下三种

多渠道打包方案	github链接
packer-ng-plugin(V2版本)	https://github.com/mcxiaoke/packer-ng-plugin
美团方案	https://github.com/Meituan-Dianping/walle
APKChannelPackage	https://www.cnblogs.com/qcloud1001/p/6758233.html

2.3 支持V2多渠道打包方案的使用

由于支持V2签名的多渠道的打包方案采用的都是同一技术方案，都是在APK V2签名之后，对签名块的信息进行修改，因此本博客对应的项目采用的方案是packer-ng-plugin(v.2.0.1)。使用方法可以参考方案提供者github上的文档，在使用过程中针对方案者提出的“ V2版只支持`APK Signature Scheme v2`”存在担忧，担心最后的渠道包只支持了V2签名，没有V1签名，对最后生成的某一渠道包解压查看，发现了的META-INF文件夹下的MANIFEST.MF、CERT.SF和CERT.RSA三个文件（V1签名的产物），就放心了。

另外需要注意的地方是针对渠道统计时，获取渠道的方式需要修改一下，可参考如下

import com.mcxiaoke.packer.helper.PackerNg ; public static void init( Context context ) { String channel = PackerNg.getChannel( context ) ; UMConfigure.init( context , "***********************" , channel, UMConfigure.DEVICE_TYPE_PHONE, null) ; }

在使用packer-ng-plugin打包方案之后，140个渠道完全打包完毕花费了2分钟，速度极快。

三、总结

本博客主要是根据项目使用需要多渠道打包，针对多渠道打包进行的调用总结，希望能够对你有帮助。

参考链接

https://www.cnblogs.com/qcloud1001/p/6758233.html

https://tech.meituan.com/android-apk-v2-signature-scheme.html