Android签名机制详解：V1、V2、V3签名格式及其兼容性
签名机制，说白了就是给APK贴上一张“防伪标签”。没有它，任何人都能篡改你的代码然后重新打包。我在2017年第一次遇到V2签名不兼容老设备的问题，当时排查了两天才发现是签名方案冲突。从那以后，我对签名机制的细节就格外关注了。
从源头说起——为什么需要签名？
Android要求每个APK都必须经过数字签名才能安装。签名的目的有仨：
- 完整性校验——确保APK内容未被篡改；
- 身份验证——证明发布者是特定开发者；
- 升级权限控制——只有相同签名的APK才能覆盖安装或共享UID。
你想想看，如果一个恶意应用用你的包名重新签名，那它就能窃取你的数据。签名机制就是最后一道防线。
V1签名（JAR签名）——老祖宗
V1签名从Android诞生就有了，直到今天依然被广泛支持。它的工作原理是：
- 对APK内每个文件分别计算摘要，记录在
MANIFEST.MF中； - 再用私钥对
MANIFEST.MF的摘要签名，生成CERT.SF和CERT.RSA； - 这些签名文件放在
META-INF/目录下。
关键点：V1签名不保护APK内的META-INF/目录本身，也不保护ZIP中央目录和文件头。攻击者可以移除签名文件后重新签名，甚至直接解压修改文件再重新压缩，V1无法察觉。
我记得早期做安全加固时，反编译后只要重新打包V1签名就生效，根本不需要原签名。这也是为什么Google后来推出了V2。
V2签名（APK Signature Scheme v2）——全量保护
V2签名在Android 7.0（API 24）引入，它把签名数据插到了ZIP文件结构里——具体就是ZIP中央目录之前、文件内容之后的一个特殊区块。这样签名就覆盖了整个APK的原始字节，包括ZIP的Central Directory。
为什么要这么做？因为攻击者无法在不破坏签名的情况下插入或移除文件。V2签名的校验流程是：
- 读取APK中的签名块（APK Signing Block）；
- 找到签名块中的签名信息（可能包含多个签名）；
- 校验整个APK的字节范围（从文件开始到签名块之前）是否与签名摘要匹配；
- 校验签名证书的合法性。
注意：V2签名只适用于Android 7.0及以上。如果你要兼容4.x设备，必须同时保留V1签名。我曾在项目里只打了V2签名，结果在Android 6.0手机上安装直接崩——提示“解析包时出现问题”。
V3签名（APK Signature Scheme v3）——轮转密钥
V3签名在Android 9.0（API 28）引入，结构基本和V2一样，但增加了密钥轮转（Key Rotation）能力。你可以用旧证书签名升级包，同时附带新证书的证明链。这样当开发者更换签名密钥时，用户不需要卸载重装。
| 特性 | V1 | V2 | V3 |
|---|---|---|---|
| Android版本支持 | 全部 | Android 7.0+ | Android 9.0+ |
| 保护范围 | 仅文件内容 | 整个APK字节 | 整个APK字节 |
| 密钥轮转 | 不支持 | 不支持 | 支持 |
| 签名数据位置 | META-INF/ | APK Signing Block | APK Signing Block |
兼容性——多签名共存方案
现实世界哪有那么理想？你的应用可能要跑在Android 4.4到Android 13上。怎么办？签名共存。现代的打包工具（如apksigner、gradle plugin）默认会同时生成V1+V2+V3签名。系统在安装时会根据其支持的版本选择最高版本的签名进行校验。
具体规则：
- Android 7.0+优先校验V2签名，如果V2签名有效则跳过V1；
- Android 9.0+优先校验V3签名，如果V3无效才退而使用V2；
- 低版本Android只识别V1签名。
避坑指南：我曾经用Android Studio打Release包，默认勾选了V1和V2。结果上传到Google Play后被拒，原因是V1签名被标记为“不安全”。建议新应用和目标API 30+的应用只保留V2+V3签名，但前提是确认最低支持版本在Android 7.0以上。如果还要兼容5.x、6.x，必须保留V1。
签名方案选择决策树
实战中的签名校验崩溃场景
我们这章是讲签名机制，但既然课程题目是《APK签名校验失败启动崩溃复现实战案例》，我提前剧透一个典型场景：
曾经有个项目：开发同学用V2签名打包，发布后发现在某些国产Android 7.0手机上启动就闪退。日志里报“Signature verification failed”。排查发现厂商定制系统把V2签名校验做得特别严格，而同时APK里残留了旧的V1签名文件导致冲突。解决方案是清理所有签名后重新用apksigner sign统一签名，并保证V1/V2签名使用同一套证书。
嗯，这里要注意一个细节：build.gradle里配置v1SigningEnabled true和v2SigningEnabled true只是告诉打包工具是否生成对应签名块，但如果你用了多个签名工具（比如先手动签V1再用Android Studio签V2），很容易出现签名不一致。
// 推荐做法：统一使用 apksigner
apksigner sign --ks my.keystore --ks-key-alias myalias --out app-release-signed.apk app-release-unsigned.apk
// 默认会同时生成V1和V2签名（兼容Android 7以下）
// 如果只想要V2+V3，可以加参数：
apksigner sign --v1-signing-enabled false --v2-signing-enabled true --ks my.keystore ...小结
V1、V2、V3签名各自有明确的应用场景和兼容性边界。记住一条原则：尽量使用最新签名方案，但不要贸然放弃老版本兼容。从Android 9开始，Play Console强制要求使用V2或V3签名上传。我个人的习惯是：所有targetSdkVersion 29+的应用只用V2+V3，同时确认最低支持版本大于等于Android 7.0；如果还要兼容6.x及以下，老老实实保留V1。