Cordova构建安卓APK经zipalign对齐后安装失败、Play报签名异常

该问题的核心为签名与对齐操作流程错位、工具混用导致签名块被意外剥离，具体成因如下：

• 核心流程顺序错误
  安卓官方规定APK处理的固定顺序为「先zipalign对齐，后签名」。实际操作完全颠倒了这个顺序：不管是Cordova自动构建生成的带默认签名的release包，还是手动用jarsigner完成签名的APK，在已经带完整签名的状态下再执行zipalign，工具会重写APK的存储结构，直接把APK尾部专门存储v2/v3签名的独立块完全抹除。但META-INF目录下的v1签名残留文件（比如CERT.SF、CERT.RSA）依然保留，这就直接触发了Google Play的报错：文件记录了APK曾经使用v2方案签名，但实际包内已经找不到对应的v2签名块，属于典型的签名被剥离场景。
• 新旧签名工具混用导致校验失效
  手动使用的jarsigner是仅支持v1签名的老旧工具，本身不具备写入v2/v3签名的能力。之前单独用jarsigner签的包之所以能正常安装，是因为它从始至终没有生成过v2签名块，跑zipalign时也没有需要被剥离的内容。但如果是Cordova高版本构建生成的release包，会默认通过内置的apksigner自动写入v2签名，这时候手动再执行zipalign重写包结构，不仅会抹掉v2签名，还可能破坏v1签名记录的文件哈希校验值，最终导致安卓系统安装时全量校验不通过，弹出「应用未安装」的提示。而zipalign本身的校验逻辑仅检查4字节边界的对齐情况，不会校验签名完整性，所以哪怕签名已经被破坏，它依然会返回「Verification successful」的提示。
• Cordova内置流程的重复操作冲突
  Cordova 9.0以上版本的安卓构建链路，本身已经内置了「未签名包自动对齐+apksigner全量签名」的完整流程，配置build.json写入keystore信息后，生成的app-release.apk本身就是完成对齐、带完整v1/v2签名的可直接发布的安装包。构建完成后手动再次执行zipalign，属于对已完成全流程的产物进行二次结构重写，必然会破坏原有内嵌的签名块，最终导致包校验失败。

规避这类问题的正确操作逻辑：

1. 从Cordova构建产物目录找到未签名的unsigned.apk文件，对该文件执行zipalign对齐操作
2. 对对齐后的未签名APK，使用apksigner工具配合自定义keystore完成全量签名，工具会自动写入兼容各安卓版本的v1/v2/v3签名块
3. 禁止在签名完成后，再对APK执行任何会修改包结构的操作（包括二次zipalign、压缩包重打包等）

内容的提问来源于stack exchange，提问作者Raishav Hanspal