签名机制
https://source.android.com/security/apksigning/
http://zzqhost.com/2017/06/17/Android%E7%AD%BE%E5%90%8D%E5%8E%9F%E7%90%86%E5%89%96%E6%9E%90/
V1签名机制
https://blog.csdn.net/asmcvc/article/details/9311827
https://blog.csdn.net/asmcvc/article/details/9312021
https://www.cnblogs.com/plokmju/p/8482993.html
https://cloud.tencent.com/developer/article/1006237
V1签名机制比较简单，主要设计三个文件，分别是自签名的证书CERT.RSA， MANIFEST.MF和CERT.SF，首先对每一个文件进行sha1并进行base64编码，生成MANIFEST.MF文件，然后对MANIFEST.MF这个文件进行sha1和base64，然后对MANIFEST.MF每一个条目进行sha1和base64，其中CERT.RSA包含签名者公钥，是一种pkcs7,p7b的格式，可以直接在windows改名字就可以看到了。校验也比较简单，首先校验CERT.RSA中的自签名证书，然后校验CERT.SF，证明文件MANIFEST.MF是正确的，然后对每一个文件进行校验，看是否被篡改，就结束。那么这里有天生的缺陷，没有对META-INF下的其他文件进行校验，也没有对ZIP包其他字段进行校验，那么可以利用 Zip 格式的特点，修改Comment Length和File Comment两个字段，不会对ZIP文件造成破坏，比如写个渠道信息。
V1签名机制存在的问题
Apk包在安装的时候，是按照从(3)到(1)的顺序依次校验的，先用公钥还原签名信息，然后和.SF文件中的信息比对，然后用同样的摘要算法对.MF文件里面的每一个条目计算对应的摘要信息，然后比对.MF文件是否一致。
在这个过程中，我们发现有两点：
(1) 在校验的过程中需要解压，因为.MF文件的摘要信息是基于原始未压缩文件内容，因此在校验的时候就需要解压出原始数据，而这个解压操作无疑是耗时操作。
(2) apk包的完整性校验不够强。这里可以看到如果我们在apk签名后，如果对apk包中没有涉及到原始文件内容的数据块做改变那么这层校验机制就会失效（如直接通过二进制改变apk包的无关数据块如核心中央目录注释字段写一些无关注释，然后用zipalign工具对齐，则apk包还是可以正常安装的，这样就绕过了v1层的校验机制）
V2签名机制
https://tech.meituan.com/android-apk-v2-signature-scheme.html
V2签名机制，是一种增强的ZIP包签名机制，先分析下格式如下
整个APK（ZIP文件格式）会被分为以下四个区块：
Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
APK Signing Block
ZIP Central Directory
ZIP End of Central Directory
那么v2签名能够对除了apk signing block以外的所有部分进行校验，如果有问题，那么就不能安装apk，相对v1来说更为安全。Apk signing block字段是可以进行更改的，不受签名约束，这部分格式如下，可以通过在id-value中多添加一些信息对，而不会改变apk的签名信息，以此实现渠道信息的添加。
@+0 8 这个Block的长度（本字段的长度不计算在内）
@+8 n 一组ID-value
@-24 8 这个Block的长度（和第一个字段一样值）
@-16 16 魔数 “APK Sig Block 42”
多渠道打包：
https://www.jianshu.com/p/332525b09a88
http://zzqhost.com/2017/06/18/Android%E6%89%93%E6%B8%A0%E9%81%93%E5%8C%85%E6%96%B9%E6%A1%88%E6%80%BB%E7%BB%93/
http://yifeiyuan.me/2017/01/16/muitl-channel-pkg-compare/
https://github.com/GavinCT/AndroidMultiChannelBuildTool zip渠道打包 v1 META-INF
https://github.com/mcxiaoke/packer-ng-plugin packer v1 v2
https://github.com/Meituan-Dianping/walle walle v2签名
多渠道打包的方案，也是基于v1和v2签名的一些固有特性来进行的。主要有code/manifest硬编码，productFlavors, zip meta-inf， zip comment注释， v2 apk signing block修改的几种方式。
Flavors
在AndroidManifest.xml中配置一个meta-data：
<meta-data
android:name="UMENG_CHANNEL"
android:value="${CHANNEL_NAME}"/>
然后在app/build.gradle里配置productFlavors：
productFlavors {
def path = "channels.txt"
file(path).eachLine { channel ->
"$channel" {
manifestPlaceholders = [CHANNEL_NAME: channel]
}
}
}
PS：channels.txt 是渠道列表文件，每一行代表一个渠道，这样方便管理。
打包方法
使用 ./gradlew assembleRelease命令，就可以打出多渠道的包了。
原理
该种方式的打包原理是利用了 Gradle 的flavors功能来实现的，渠道的获取是通过如下代码方式获取。
ApplicationInfo appInfo = cxt.getPackageManager().getApplicationInfo(cxt.getPackageName(), PackageManager.GET_META_DATA);
String channel = String.valueOf(appInfo.metaData.get("UMENG_CHANNEL"));
优缺点
优点：
简单，易懂，没什么门槛，也不需要依赖其他工具与插件。
Gradle强大的flavor功能，可以实现不同渠道拥有不同的代码实现，可以给渠道做定制包。
扩展性强大，没有兼容性问题。
缺点：
打包速度极慢，因为每个渠道包都是从“0到1”，渠道一多，打包时间以小时为单位。
PS：我们 App 几百个渠道，用这种方式打包需要2多个小时，怎么受得了？。
所以，该方式适合渠道不多的时候使用，或者不同渠道需要使用不同的代码。
Wiki
