V1签名 (JAR签名)
- 最传统的签名方式
- 在APK的META-INF目录下生成三个文件：
- MANIFEST.MF
- CERT.SF
- CERT.RSA
- 优点：兼容性好，支持所有Android版本
- 缺点：签名速度较慢，安全性相对较低
V2签名 (APK Signature Scheme v2)
- Android 7.0 (API 24)引入
- 在APK文件中添加一个APK Signing Block
- 优点：
- 签名速度更快
- 安全性更高
- 可以防止APK被篡改
- 缺点：仅支持Android 7.0及以上版本
V3签名 (APK Signature Scheme v3)
- Android 9.0 (API 28)引入
- 支持密钥轮换
- 优点：
- 允许在APK更新时更换签名密钥
- 向后兼容V2签名
- 提供更好的安全性
- 缺点：仅支持Android 9.0及以上版本
V4签名 (APK Signature Scheme v4)
- Android 11 (API 30)引入
- 基于APK内容生成签名文件
- 优点：
- 支持Google Play的APK签名服务
- 可以验证APK的完整性
- 支持分块验证
- 缺点：仅支持Android 11及以上版本

v1签名的逻辑

签名生成逻辑

扫描apk文件，对apk中的文件计算其sha256摘要，并用base64编码。然后在文件中针对每一个文件生成一个条目，条目有文件名，以及其sha256摘要。

最后生成一个MANIFEST.MF文件。

*.SF文件是用来防止MANIFEST.MF被篡改。

它会首先生成MANIFEST.MF的摘要(base64编码)，放在文件头中。然后针对其中的每一个entry条目，再生成一次摘要(base64编码)。

.RSA文件，对.SF计算其sha256摘要，用私钥计算出签名。然后把签名和公钥信息一起写入到CERT.RSA文件中。*

校验SF文件是否被篡改，计算SF文件的摘要，然后用RSA文件中的公钥解密RSA文件中签名得到的摘要，如果两者一致就进入下一步
校验MANFEST.MF文件的完整性，计算MANFEST.MF文件的摘要，和SF中的摘要条目进行对比，如果都一致则逐一校验MANFEST.MF各个文件条目的完整性。

v2签名不再像v1签名一样基于文件，它是基于块的，将原始zip包分解成1M的小块，对每一个小块进行摘要，最后将这些摘要拼起来进行签名。v2签名是有一个单独的Apk Sign block放置到zip文件中。

v3签名在v2签名的基础上增加了‘密钥轮替‘机制，保证如果准备安装的apk的签名替换了，也能够安装成功

v4签名增加了对apk增量安装的支持。

对齐操作应该在签名之前。因为对齐操作可能会更改apk内容。这个时候签名就失效了。