上一节介绍到多渠道打包的快速，他是如何如此迅速的完成打包的？
问题1：如何不修改签名的情况下，网APK中注入渠道信息？？？
先不急接着往下看。
一.APK签名介绍:
1.APK 签名方案
Android 支持以下三种应用签名方案：
- v1 方案：基于 JAR 签名。
- v2 方案：APK 签名方案 v2（在 Android 7.0 中引入）。
- v3 方案：APK 签名方案 v3（在 Android 9 中引入）。
为了最大限度地提高兼容性，请按照 v1、v2、v3 的先后顺序采用所有方案对应用进行签名。与只通过 v1 方案签名的应用相比，还通过 v2+ 方案签名的应用能够更快速地安装到 Android 7.0 及更高版本的设备上。更低版本的 Android 平台会忽略 v2+ 签名，这就需要应用包含 v1 签名。
图 1. APK 签名验证过程
验证程序会对照存储在“APK 签名分块”中的 v2+ 签名对 APK 的全文件哈希进行验证。 该哈希涵盖除“APK 签名分块”（其中包含 v2+ 签名）之外的所有内容。在“APK 签名分块”以外对 APK 进行的任何修改都会使 APK 的 v2+ 签名作废。v2+ 签名被删除的 APK 也会被拒绝，因为 v1 签名指明相应 APK 带有 v2 签名，所以 Android 7.0 及更高版本会拒绝使用 v1 签名验证 APK。
2. V1签名：是一个基于JAR的签名，保护ZIP中的文件
首先我们找一个已经签名的apk文件，修改后缀名为zip，然后解压。可以看到里面有一个META-INF文件夹，里面就是签名验证的文件。有三个文件MANIFEST.MF、CERT.SF、CERT.RSA分别保存着不同的签名信息。
2.1 MANIFEST.MF文件
1. Manifest-Version
用来定义manifest文件的版本，例如：Manifest-Version: 1.02. Created-By
声明该文件的生成者，一般该属性是由jar命令行工具生成的，例如：Created-By: Apache Ant 1.5.13.Name
声明了apk中所有的文件。4.SHA-256-Digest
对apk中所有文件中对应name的文件的校验码。文件内容发生改变时校验码也随之发生改变，防止文件被修改。
apk在安装的时候，会根据文件内容计算出对应的SHA-256校验码，如果生成的校验码与MANIFEST.MF中的信息不符，则安装失败。
2.2 CERT.SF文件
除了保存APK所有文件的名称和校验码之外，还保存了MANIFEST.MF文件的校验码。
2.3 CERT.RSA文件
签名的时候需要给一个证书，证书里面有公钥和私钥。
RSA文件的内容就是：使用私钥计算CERT.SF文件的数字签名 + 包含公钥的证书。
所以v1的签名过程为：
CERT.RSA文件 —》保护CERT.SF文件 —》保护MANIFEST.MF文件 —》保护apk所有的文件
v1签名：保护的是apk中已存在的文件不被修改。
2.4 v1多渠道
APK文件就是一个ZIP压缩包
3. V2 V3签名：保护整个APK(除特殊区域外)的字节数据
部分知识点来自于Android source 网站。
搭载 Android 7.0 及更高版本的设备支持 APK 签名方案 v2（v2 方案）及更高版本的方案（在 Android 9 中，v2 方案已更新为 v3 方案，以便在签名分块中包含其他信息，但在其他方面保持相同的工作方式）。该方案会对 APK 的内容进行哈希处理和签名，然后将生成的“APK 签名分块”插入到 APK 中。
在验证期间，v2+ 方案会将 APK 文件视为 blob，并对整个文件进行签名检查。对 APK 进行的任何修改（包括对 ZIP 元数据进行的修改）都会使 APK 签名作废。这种形式的 APK 验证不仅速度要快得多，而且能够发现更多种未经授权的修改。
新的签名格式向后兼容，因此，使用这种新格式签名的 APK 可在更低版本的 Android 设备上进行安装（会直接忽略添加到 APK 的额外数据），但前提是这些 APK 还带有 v1 签名。
3.1 V2签名
验证程序会对照存储在“APK 签名分块”中的 v2+ 签名对 APK 的全文件哈希进行验证。 该哈希涵盖除“APK 签名分块”（其中包含 v2+ 签名）之外的所有内容。在“APK 签名分块”以外对 APK 进行的任何修改都会使 APK 的 v2+ 签名作废。v2+ 签名被删除的 APK 也会被拒绝，因为 v1 签名指明相应 APK 带有 v2 签名，所以 Android 7.0 及更高版本会拒绝使用 v1 签名验证 APK。
APK 签名方案 v2 是一种全文件签名方案，该方案能够发现对 APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。
使用 APK 签名方案 v2 进行签名时，会在 APK 文件中插入一个 APK 签名分块，该分块位于“ZIP 中央目录”部分之前并紧邻该部分。在“APK 签名分块”内，v2 签名和签名者身份信息会存储在 APK 签名方案 v2 分块中。
如下图所示：APK 签名分块的具体格式。
最值得注意的是里面的两个模块：键值对 和 magic(魔数)
- 键值对： 该分块包含多个“ID-值”对，所采用的封装方式有助于更轻松地在 APK 中找到该分块。APK 的 v2 签名会存储为一个“ID-值”对，其中 ID 为 0x7109871a。
- magic(魔数)： 用于标记文件格式
3.2 V2签名保护的内容
为了保护 APK 内容，APK 包含以下 4 个部分：
- ZIP 条目的内容（从偏移量 0 处开始一直到“APK 签名分块”的起始位置）
- APK 签名分块
- ZIP 中央目录
- ZIP 中央目录结尾
APK 签名方案 v2 负责保护第 1、3、4 部分的完整性，以及第 2 部分包含的“APK 签名方案 v2 分块”中的 signed data 分块（也就是ID为：0x7109871a的数据）的完整性。
按照V1签名加入渠道信息，会让1、3、4中字节数据发生变化，导致签名验证失败!
在APK签名块中添加一个ID-Value，存储渠道信息。
3.3 添加渠道信息的步骤
1.解析APK，判断是否使用v2/v3签名，定位v2/v3签名块
2.在签名块中添加包含渠道信息的ID-Value
3.拷贝原APK，并修改签名块数据生成带有渠道信息的APK
方案落地：（怎么判断使用的是V2签名？如何定位签名块？签名块从第几个字节开始？）
EOCD格式（第四部分）：如下图所示
通过这个数据可以确定第三部分的位置
找到位置之后，在往前面读取16个字节（magic）。如果这16个字节匹配那就使用的是V2签名。
然后根据size of block来读取第二部分即可。最后找到键值对中的渠道信息即可。
3.4 V3签名
v3 APK 签名分块的格式与 v2 相同。APK 的 v3 签名会存储为一个“ID-值”对，其中 ID 为 0xf05368c0。
新版v3签名在v2的基础上，仍然采用检查整个压缩包的校验方式。不同的是在签名部分增可以添加新的证书（Attr块）。在这个新块中，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名。
v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。
其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。
二、额外知识点：
1.在app的安装过程中，使用PMS（PackageManager Service）来负责安装，他在安装apk文件的时候会复制一份到date/app对应的软件目录下。
2.假如一个png格式的图片，修改后缀为jpg。那么这张图片的格式是什么？
答案是png格式
文件后缀名的意义：让程序识别格式，选择不同的处理方式（打开方式）。假如发生了错误的修改，这个后缀名就没有意义了。
3.使用Glide加载图片时经常访问的图片没有后缀名：他是怎么工作的？
我们不知道图片的格式（jpg png webp gif）
glide: 读取文件魔数，来确定格式，然后根据格式解码