你是不是也遇到过这种情况：手头拿到一个已经签好名的APK，但因为渠道分包、测试转正式、或者客户要求换一套证书，需要对这个APK做一次“二次签名”。直接把新签名压上去？装的时候多半会翻车。重签这个操作看着简单，真正做起来有一堆细节，核心是“先清掉旧签名、再按规范重新签名”，顺序搞反、工具用错、对齐漏掉，都会让你在安装那一步百思不得其解。
这篇记录就把“对已签名APK进行再次签名”这件事讲透：从APK签名的底层逻辑说起，给出命令行和可视化两套方案，再拆解成可直接照抄的四步流程，最后附上我实际踩坑总结出来的问题排查清单。无论你是刚开始接触Android打包的开发者，还是负责发版运维的工程同学，照着这篇操作都能少走弯路。
1. 为什么“已签名APK再签名”是个坑
1.1 APK签名不是“盖个章”那么简单
很多人对APK签名的理解停留在“签名就是给包盖个章，证明这个包是我出的”。从结果上看这个理解没错，但从实现机制上看，APK签名远比“盖章”复杂，它更像是一套覆盖整个文件的“封条+防伪码”体系。
APK本质上就是一个ZIP压缩包，里面除了代码、资源、清单文件，还藏着签名信息。Android系统在安装APK时，会做两件事：第一，校验APK内容是否被篡改过，也就是把APK里的每个文件都算一遍摘要，和签名文件里记录的摘要做比对；第二，校验签名证书是否可信、证书链是否完整。任何一个环节对不上，系统都会直接拒绝安装，表现就是常见的“应用未安装”或者安装按钮点击后毫无反应。
所以对已签名APK再次签名，最忌讳的想法就是“我不管里面有什么签名，只要最后用我的key签一遍，装得上就行”。这种做法等于把一个已经封好的信封直接贴上新封条，里面旧的封条和新封条相互冲突，系统一拆信封就发现不对劲。
1.2 旧签名到底藏在APK的什么地方
要理解“再次签名”为什么需要特殊处理，得先知道旧签名藏在哪儿。
经典签名方案（也叫v1签名）会把签名文件放在APK的META-INF目录下，通常有三个文件：MANIFEST.MF、CERT.SF和CERT.RSA。MANIFEST.MF记录APK内所有文件的摘要，CERT.SF是对MANIFEST.MF的签名保护，CERT.RSA则包含签名者的公钥证书和数字签名。这套机制从Android早期一直沿用至今，兼容性最好。
Android 7.0之后推出了v2签名方案，签名数据不再放在META-INF目录里，而是单独塞进APK文件中间的一个特殊区域，叫APK Signing Block。这个区域在ZIP文件结构里是“不可见”的，普通解压软件不会把它当文件解出来，但系统校验签名时会读取它。
这就带来一个关键问题：如果你拿着一个已经带v1和v2签名的APK，不清理旧签名就直接往上签，META-INF里的旧CERT文件和新CERT文件可能并存，旧的v2签名块也可能残留在文件中。系统在校验时按自己的规则读取签名信息，读到新旧混杂的内容，自然就会报错。这也是为什么很多人在重签之后，明明签名步骤没报错，装上就是“应用未安装”。
1.3 覆盖安装时的“签名一致性检查”
除了首装时的完整性校验，Android还有一个特别容易踩的坑：覆盖安装时的签名一致性检查。
当你的设备上已经安装了某个应用，再安装同包名的新APK时，系统会强制比较已安装应用的签名和待安装APK的签名。只要两个签名证书不一致，无论你用的keystore有多正规、签名算法多安全，系统都会直接拒绝覆盖安装，报错信息一般是“应用未安装”或“签名不一致”。
我见过不少同事在测试重签包时，明明是新包覆盖老包，却摔在签名一致性上。解决思路很简单：要么在测试机上先卸载旧应用再安装新包，要么在重签之前确认新旧包使用的是同一个证书。如果只是为了验证签名流程是否跑通，建议直接用“先卸载再安装”的方式，省得被这个检查干扰。
2. 工具选型与前置准备
2.1 官方三件套：apksigner、zipalign、keytool
要做一次正经的APK重签，我推荐优先使用Android官方SDK自带的工具，分别是apksigner、zipalign和keytool。这三个工具都在Android SDK的build-tools目录下，版本建议用build-tools 24.0.3及以上，因为apksigner是从这个版本开始内置的。
apksigner是签名主工具，负责给APK生成v1、v2、v3签名。zipalign负责APK对齐，目的是让APK内未压缩的数据在文件中的起始位置对齐到4字节边界，这样Android系统在安装和运行时可以用更高效的方式读取数据，减少内存拷贝。keytool是JDK自带的工具，用来生成和管理keystore，也就是签名用的密钥库。
很多老教程喜欢用JDK自带的jarsigner来做APK签名，这里我多说一句：jarsigner只能生成v1签名，对v2和v3签名方案没有原生支持。如果你在新项目里还在用jarsigner，建议尽早切换到apksigner，尤其是targetSdkVersion较高的应用，分发渠道和系统都对签名方案有严格要求，只用v1签名容易在部分新设备上被拒。
2.2 各家工具怎么选：命令行还是GUI
命令行工具灵活、可脚本化，适合一次配置、多次执行的场景。比如你手头有几百个渠道包要重签，写一个shell脚本循环处理，几分钟就能跑完。但命令行对不熟悉终端操作的同事不太友好，第一次上手容易因为路径写错、参数漏传而反复折腾。
可视化方案也有不少选择。市面上常见的Android逆向和打包工具都提供签名功能，操作上一般是打开APK、选择keystore、点击签名，几步就能完成。Android Studio自带的Build > Generate Signed Bundle/APK也能用来签名，但它面向的是“从源码构建时签名”的场景，对“拿一个现成的已签名APK做重签”这件事，操作上反而绕。如果你只是偶尔签一个包，用可视化工具省心很多；如果你需要长期、批量处理，老老实实把命令行这套练熟，一劳永逸。
2.3 快速准备一个测试keystore
很多人在尝试重签时，手边没有可用的keystore，只能拿公司正式key来做测试。这是很危险的习惯：正式key一旦在测试过程中泄露，整个应用的安全性就白搭了。我的建议是专门准备一个用于测试和本地练习的keystore，用keytool一条命令就能生成。
keytool -genkeypair -keystore test.jks -alias test -keyalg RSA -keysize 2048 -validity 10000 -storepass 123456 -keypass 123456这条命令会生成一个名为test.jks的keystore，别名test，RSA密钥长度2048位，有效期10000天。RSA 2048是目前Android签名的主流密钥长度，兼容性和安全性都有保障。生成过程中还会要求填写组织信息，测试用的话随便填就行。记住storepass和keypass两个密码，后面签名和校验时都要用到。
3. 实操：四步完成APK再次签名
3.1 第一步：备份原始APK
这个步骤听起来多余，但踩过坑的人都会知道它的分量。重签操作会直接改变APK的二进制内容，一旦你把原包覆盖了，再想拿原包做对比、回退、或者重新处理，都只能抓瞎。特别是从客户或第三方拿到的APK，如果对方没有留存原包，你这边又没备份，出了问题很难交代。
建议实际操作时把原始APK复制一份，放到单独目录，命名为“原包-未签名”之类的名字，同时在旁边记录下原包的SHA-256值。这个哈希值可以用来确认后续操作过程中APK内容是否被意外改动。
sha256sum original.apk记录哈希值的好处是：万一你怀疑某个环节改变了APK结构，可以随时再算一次哈希来比对原始状态。我在实际处理渠道包时，还会顺带把APK的包名、版本号、支持的SDK版本等基础信息用aapt导出一份，方便后续核对。
3.2 第二步：检查并修复APK对齐状态
对齐这个环节最容易被忽略，但它直接关系到签名后的APK能否被系统顺利读取。在Android安装APK时，系统会尝试对APK内未压缩的数据做mmap映射，如果数据没有对齐，系统就需要在运行时进行额外的数据复制，轻则性能下降，重则导致某些机型上解析异常。
先用zipalign检查原始APK的对齐状态。
zipalign -c -v 4 original.apk这里的4表示4字节对齐，-c是check模式，-v是输出详细结果。如果输出显示“Verification successful”，说明对齐没问题；如果输出里有“verification FAILED”，就要先做一次对齐。
zipalign -f -p 4 original.apk aligned.apk-f是允许覆盖输出文件，-p表示对未压缩的.so库也做4字节对齐。这个参数对于包含原生库的应用尤其重要，很多只跑zipalign不加-p的教程，在处理带native库的APK时都会埋下隐患。对齐完成后，后面的操作都基于aligned.apk这个文件。
3.3 第三步：删除旧签名信息，生成新签名
这一步是整个重签流程的核心，也是最容易出问题的地方。首先删除APK里的旧签名文件。对v1签名来说，就是把META-INF目录下旧的签名文件清掉。虽然apksigner在签名时会尝试替换签名块，但为了减少不确定因素，我习惯先把META-INF整个目录从APK里移除。
zip -d aligned.apk "META-INF/*"这条命令会删除APK中META-INF目录下所有文件。如果你用的是Windows环境，也可以用7-Zip打开APK，手动删除META-INF目录，效果相同。唯一要注意的是：删除操作必须只动META-INF目录，其他任何文件都不应该被修改。有经验的同事会在这之后再做一次解压检查，确认APK内部结构和原来的只差了META-INF。
接下来用apksigner执行新签名。
apksigner sign --ks test.jks --ks-key-alias test --ks-pass pass:123456 --key-pass pass:123456 --out signed.apk aligned.apk这个命令的含义是：使用test.jks这个keystore，别名为test，keystore密码和key密码都是123456，对aligned.apk签名，输出为signed.apk。apksigner会默认同时生成v1和v2签名，兼容性和安全性都能兼顾。如果你的应用targetSdkVersion较高、只面向Android 7.0以上设备，还可以追加--v1-signing-enabled false参数，只生成v2签名，这样APK体积会更小，签名校验路径也更短。
需要特别提醒：顺序一定是“先对齐、再签名”。因为v2签名块位于APK文件中央，签名之后再对APK做任何字节级修改都会导致v2签名失效。先对齐再签名，签名块就落在最终位置的字节流里，系统安装时直接读出来校验即可。
3.4 第四步：校验签名结果，确认无误
签名完成不等于万事大吉，校验是必不可少的一步。用apksigner的verify命令检查签名的有效性，以及证书信息是否和预期一致。
apksigner verify --print-certs signed.apk输出里会包含证书的MD5、SHA-1、SHA-256指纹，以及证书DN信息。对照一下你生成keystore时填写的组织信息，确认无误后再继续。除了证书指纹，还可以确认签名方案：apksigner verify --verbose signed.apk，输出里会明确列出这个APK包含v1、v2还是v3签名，一目了然。
在真机或者模拟器上安装验证也很有必要。如果设备里已经装了老版本，建议先卸载，再安装signed.apk，避免被覆盖安装的签名一致性检查干扰。安装成功并打开之后，再从设备里把已安装的APK拉出来，和本地signed.apk对比一下指纹，确保安装的确实是你处理过的包。
4. 常见问题与排查技巧实录
4.1 安装时报“应用未安装”
这是重签后最常见的报错，原因通常是几种情况叠加。第一步先检查APK是否能通过apksigner verify，如果verify都报错，说明签名本身就没签对。常见原因包括：META-INF删除不彻底，旧的CERT文件和新签名文件并存；或者是keystore密码填错，导致签名过程没有真正完成；还有一种情况是APK在签名之后又被人为改动过，破坏了v2签名块。
排查时按照“先验签、再对齐、后安装”的顺序来。先apksigner verify看签名状态，再zipalign -c看对齐状态，最后adb install看具体报错信息。大部分问题都能通过这个流程定位。
4.2 覆盖安装提示签名不一致
这个问题我在前面提到过，本质上是Android系统对覆盖安装的签名一致性检查在起作用。如果你已经确认新旧APK使用的是同一个keystore和同一个别名，仍然提示不一致，那么重点检查一下签名过程中是否换过key。我自己就遇到过类似的事：明明用的是同一个keystore，但命令行参数里alias写错了，apksigner没报错，实际却签成了另一个别名对应的证书。这种情况下证书指纹完全不同，覆盖安装自然失败。
处理办法很简单：别在覆盖安装上较劲，测试阶段先卸载旧包再装新包。同时养成签完就打印证书指纹的习惯，用之前记录的原包指纹做对比，防患于未然。
4.3 v2签名校验失败，verify报错
如果你发现apksigner verify在某个包上通不过，而签名过程没有任何报错，大概率是签名前的APK结构已经存在异常。一种典型场景是：原始APK里带着v2签名块，但你在删除META-INF时没有处理v2块，apksigner在写入新v2签名块时和旧v2块产生了冲突。
这种情况下我建议走“解包重打包”的兜底方案：把APK当作ZIP解压到临时目录，用zip命令重新打包，再对新包做对齐和签名。这样可以把APK内部所有历史签名痕迹都清干净，得到一个结构完全干净的文件。唯一的代价是，重新打包可能改变原有文件的压缩方式，建议打包时保持默认压缩参数，不要为了体积优化去调整压缩级别。
4.4 对齐和签名顺序搞反了
顺序反掉这种错误，我自己早期就犯过不止一次。如果先签名再zipalign，那么zipalign会改变APK文件内容，v2签名块因为内容变化而失效，最终安装时被系统判定为签名不合法。如果先签名再对齐只是为了节省一步操作，最后往往要返工重来。
我的习惯是写成一条固定的流水线命令，减少手动操作出错的概率。比如把“对齐、验证对齐、删除META-INF、签名、验证签名”这五个动作写成一个sh脚本，每次重签前先跑脚本，再人工检查输出。脚本化还有个额外好处：换一台电脑、换一个同事来操作，也能保持结果一致。
5. 延伸场景：签名二次处理的其他方向
5.1 多渠道打包与签名的关系
很多应用在发布时要打几十个渠道包，每个渠道包的包名相同、内容基本相同，差异只体现在渠道ID等少量配置上。比较传统的做法是打好一个基础包，然后针对每个渠道分别生成渠道包，再对每个渠道包做一次签名。这种场景下，“对已签名APK再次签名”就变成了流水线里的固定环节。
实际操作中，渠道包的重签和普通重签流程一致，但有几个额外讲究。一是尽量复用同一个keystore，保证所有渠道包签名一致，这样用户在渠道之间覆盖安装时不会碰到签名冲突的问题；二是渠道信息的写入方式要慎重，如果把渠道ID写进META-INF里，注意不要和签名信息混在一起，否则每次加渠道都得重签；三是如果使用了v2签名方案，渠道信息的写入必须发生在签名之后，否则任何内容改动都会破坏签名。目前市面上一些成熟的渠道打包方案会把渠道ID放在APK的追加注释区，就是为了避开对v2签名块的破坏。
5.2 加固后、分发前的重签场景
应用加固是另一个常见的重签刚需。加固服务商通常会把APK的代码和资源做处理，生成加固包。加固过程不会保留你原来的签名，因为加固本身就是对APK字节流的深度修改，原签名在加固完成后必然失效。所以加固后的APK需要重新签名，才能正常安装和上架。
这个场景下要注意的是：加固包在重新签名之前，同样要检查对齐状态。部分加固服务商在输出加固包时不会帮你做对齐，直接签名会导致安装或运行时的性能问题。我在处理加固包时，会把“zipalign校验”放在签名前面的固定步骤里，一旦发现未对齐，先对齐再签，绝不图省事跳过。
5.3 分发渠道对签名方案的硬性要求
随着Android系统版本迭代，签名方案的演进和分发渠道的准入要求越来越挂钩。目前大部分主流通用市场和应用分发平台，对APK的签名方案都有基础要求，尤其是在targetSdkVersion升级到较高版本之后，纯v1签名方案的APK在很多渠道会直接被拒绝上架。
如果你长期接触海外业务，对v2甚至v3签名的要求会更敏感。建议每次重签前先确认APK原本的签名方案，用apksigner verify --verbose看一遍。如果你的新签名方案低于原包方案，可能出现“签名降低了”的提示，某些渠道会判定为异常包。保持新签名方案不低于原包方案，是一个省心的原则。
写在最后的小建议
最初做重签操作时，我也栽过几个跟头，印象最深的是在META-INF没清干净的情况下直接跑apksigner，签名日志完全正常，一安装就报错，排查了好半天才发现是旧签名文件在作怪。后来我把流程固定成“备份、对齐、清旧签、新签名、验证”这五步，每次操作就再没出过岔子。
另外想提醒一句：测试重签流程时，别拿正式keystore去试，专门准备一把测试key，密码也设得简单些。等流程完全跑通、确认没有问题之后，再用正式key执行真正要发布的包。重签工具本身不复杂，但在这个过程中因为参数写错、路径不对把正式key乱签一通，这种低级事故才是真正耗时间的。
如果你后续遇到“签名看起来成功但安装就是失败”的情况，把apksigner verify --verbose的输出先跑一遍，绝大多数问题都能在里面找到线索。签名这件事，只要你把它当成“动一发而牵全身”的文件完整性操作来对待，多留点心，就能少踩很多坑。
