企业官网建设流程全解析

接手别人交过来的包，往往只有APK文件，不带源码也不带签名文件。这种情况下改点小需求、换个图标、替换渠道配置，算常见操作。可真到重新打包时，问题就冒出来了：原本的APK已经带了一个签名，硬件上没有对应的keystore，直接重打包装上手机大概率会被系统拦下来，或者在覆盖安装时提示签名不一致，闹得很不愉快。

“对已签名APK进行再次签名”这件事，是所有改包、定制、企业分发场景里绕不开的一步。它看起来只是一两条命令的事，但里面涉及签名方案、证书指纹、对齐顺序、第三方SDK校验等一系列细节。我这些年踩过不少坑，这次干脆把完整的方法、原理和排查思路一次性梳理出来，给需要的朋友留一份能直接照着操作的记录。

1. 为什么“已经签过名的APK”还要再签一次

大多数人接触到重新签名，都是从“拿到一个别人的包”开始的。但这个操作的适用范围远比想象中广，至少包括下面四类高频场景。

1.1 证书丢失之后的“救火”操作

开发老项目时有个坏习惯：签名文件随手放，密码记在本地某个角落里。等到几年后再接手这个项目，源码还在，keystore却找不到了，密码也没人记得。这时候你手里只有线上已经发布的APK，而产品经理的需求是“换一个包名重新上架”或者“改一下启动页”。那唯一的办法就是拿这个已签名的APK做二次加工，然后用自己的新证书重新签一遍。

这种场景下，原签名信息对新包已经没有任何意义，重签名更像是“把别人签过的包变成自己能签的包”。

1.2 应用市场与企业分发的强制要求

有些渠道或企业统一分发平台对证书有硬性要求：比如企业内部分发时要求所有应用使用统一的机构证书，或者应用市场要求签名证书必须与上传者身份一致。如果你的APK是外包团队做的，证书默认挂在对方手里，那上架前就需要对方做“证书迁移”，实际上就是对原APK重新签名后替换。

还有一种常见情况是定制 ROM 或政企项目。设备厂商要求所有内置应用使用企业自定义证书，方便做系统级权限申请。这时即使原包已经是正规签名，也必须换签成指定的证书。

1.3 加固、渠道包与二次开发后的必经之路

很多人遇到重签名，其实是在“加固”之后。应用加固服务的标准流程是：你提交APK给加固服务商，加固引擎对DEX做加密和抽取，再和你原来的资源一起重新组装成包。这个过程会破坏原始签名，所以加固完成后的APK必须用你自己的证书再签一次，否则根本装不上。

另外，多渠道打包工具（比如在APK尾部写入渠道信息的那种）、热修复补丁注入、插件化框架接入，本质上都会修改APK内容。只要动了包内容，原签名必然失效，重签名就是打包流水线的最后一道工序。

别小看这一步。哪怕只是往APK里加了一个无关紧要的配置文件，整个包的哈希都会变，原有签名校验立刻失败。所以“重打包”和“重签名”几乎是绑定的。

2. 先弄清签名机制再动手：证书、密钥库与签名方案的差异

重签名命令谁都会复制，但我建议先把签名本身的机制看明白，否则出了问题连排查方向都找不到。

2.1 一把私钥和一个“锁孔”：证书与密钥库

Android 应用签名本质上是对APK内所有文件的摘要做一次数字签名，用的是非对称加密：签名方持有私钥，系统/其他应用验证时使用证书中的公钥。证书里装着公钥、归属者信息、有效期等内容，由权威CA签发或自定义生成均可。

而keystore（密钥库）就是一个装着私钥和证书的加密文件。它有两种常见格式：老的JKS和新的PKCS12。现在使用Android Studio生成的.keystore或.jks都是后者。以前有人会把keystore直接当成证书，严格说不太准确，但对日常重签名操作来说，你只要记住：签名时给工具提供keystore文件路径、别名（alias）和密码，工具就能取出私钥对APK做签名。

2.2 v1、v2、v3签名方案的区别

这一点是重签名最容易出问题的根源。Android签名方案不是只有一种：

用apksigner重签名时，工具默认会按照你指定或推导出的最低支持系统版本，自动选择合适的签名方案组合。比如你的APK支持Android 6设备，那么它会同时签v1+v2，因为Android 7以下只认v1。如果只签v2，老设备会提示“没有证书”直接拒绝安装。

v3签名方案值得多说一句。它允许在证书过期或私钥泄露时，通过旧证书签发新证书，完成“平滑换证”。如果团队有长期维护计划，建议打包时直接开启v3，后面省很多事。

2.3 “再次签名”到底会覆盖掉什么

网上有些教程告诉你重签名前要删掉META-INF目录下的旧签名文件，这类说法不能一概而论。

• 使用apksigner签名时，工具会替换原有的签名块。v2/v3签名存放在APK的Signing Block中，apksigner会自动替换；v1签名存放在META-INF下，apksigner内部也会重新生成MANIFEST.MF、.SF和.RSA文件，并把旧的清掉。
• 使用jarsigner签名时，情况不一样。jarsigner默认会在META-INF里追加新的签名文件，如果原包里的旧签名没删，最后包里会同时出现两套签名信息，安装时可能报“多个签名者”的错。

所以“是否需要清理旧签名”取决于你用哪套工具。为了保险，重签后要养成用apksigner verify看的习惯，确认最终包里签名者只有一个。

3. 重签名的工具与环境准备

3.1 三条命令就能跑起来的工具链

我建议直接使用Android官方build-tools目录下的三个工具，都在本地SDK路径里：

• apksigner：负责签名和验证签名，新版build-tools默认自带
• zipalign：负责APK对齐，让资源加载更快
• keytool：JDK自带，用于生成和管理密钥库

以macOS/Linux为例，找到SDK路径后，工具一般在这里：

$ANDROID_HOME/build-tools/<版本号>/apksigner $ANDROID_HOME/build-tools/<版本号>/zipalign

Windows用户把对应路径改成%ANDROID_HOME%\build-tools\xx\apksigner.bat即可。建议把build-tools目录加进PATH，避免每次写全路径。

apksigner要求Java 8或更高版本。如果你电脑上装了多个JDK，先敲一下java -version确认版本，否则可能遇到“Unsupported class file major version”这类报错。

3.2 生成自己的签名证书

动手重签之前，先确保手上有自己的证书。如果还没有，用一行命令生成：

keytool -genkeypair -v \ -keystore my-release.keystore \ -alias myalias \ -keyalg RSA \ -keysize 2048 \ -validity 10950

参数含义：

• -keystore my-release.keystore：生成的文件名
• -alias myalias：这个钥匙在库里的别名，签名时要对应上
• -keyalg RSA：密钥算法，RSA是当前最通用的
• -keysize 2048：密钥长度，2048位是底线，不要用1024
• -validity 10950：有效期30年。如果项目会长期维护，可以直接写36500（100年）

执行后它会让你填写姓名、组织单位、城市等信息，这些信息会写进证书里。建议组织单位（OU）和城市（L）填真实可溯源的信息，因为SDK后台登记证书指纹时经常需要核对。

生成过程中会要求设置keystore密码（storepass）和key密码（keypass）。这两个密码可以不设成一样，但实践中大家通常设成同一个，避免后续工具调用时密码对不上。

3.3 为什么必须先把apksigner和zipalign的顺序搞清楚

对齐和签名这两步的先后顺序，是重签名里最容易翻车的点，我先说结论：

先对齐，后签名。

为什么会这样？zipalign会把APK内的资源文件都调整到4字节对齐的位置，让系统在运行时可以直接通过内存映射读取，减少内存拷贝。问题在于，v2/v3签名会把一个签名分块插入APK文件中间，这个操作会改变所有条目的偏移量，从而破坏先前的对齐效果。

所以正确顺序永远是：

1. zipalign对齐未签名的APK
2. apksigner签名

反过来用jarsigner这类只签v1的工具时，顺序就没那么严格。因为v1签名不改动文件内容偏移，只往META-INF里加文件。但从同时支持v1+v2+ v3的角度考虑，统一采用“先对齐再签名”的顺序最安全。

4. 两种重签名路径的完整操作

工具准备好之后，重签名实操其实就两条路：一条是官方推荐的apksigner路径，另一条是传统的jarsigner路径。我把两条路都走一遍，并告诉你各自的适用场景。

4.1 路径A：直接用apksigner重签（推荐）

拿到一个已签名的APK，比如old-signed.apk，想换成自己的证书my-release.keystore，命令如下：

先对齐：

zipalign -v 4 old-signed.apk aligned.apk

-v 4表示按4字节对齐，这是Android官方对APK的要求。执行完成后再签名：

apksigner sign \ --ks my-release.keystore \ --ks-key-alias myalias \ --ks-pass pass:你的storepass \ --key-pass pass:你的keypass \ --out final-signed.apk \ aligned.apk

参数说明：

• --ks：keystore文件的路径
• --ks-key-alias：要使用哪个别名下的钥匙
• --ks-pass：keystore文件密码，格式pass:密码
• --key-pass：钥匙密码，格式同上
• --out：输出文件名，不要直接在原文件上改，保持一个干净的可重来状态

如果你不想把密码明文写在命令行里，可以省略--ks-pass和--key-pass，apksigner会在运行时交互式地提示你输入密码。这一步建议省略，避免密码残留在shell历史记录里。

签名完成后，验证一下：

apksigner verify -v --print-certs final-signed.apk

看到输出里有Signer #1 certificate DN和指纹信息，并且没有报错，就说明重签名成功了。--print-certs会打印出证书的SHA-256指纹，后面要登记SDK指纹时直接从这里复制。

4.2 路径B：jarsigner签V1的老路子

有些环境不方便用apksigner，或者需要强制指定v1签名的兼容性测试，那就会用JDK自带的jarsigner。老Android开发者对这条命令很熟悉：

jarsigner -verbose \ -keystore my-release.keystore \ -storepass 你的storepass \ -keypass 你的keypass \ -sigalg SHA256withRSA \ -digestalg SHA-256 \ aligned.apk \ myalias

这条命令直接在原文件aligned.apk上做签名。如果你不想破坏原文件，可以先复制一份。签名完成后同样需要验证，老办法是：

jarsigner -verify -verbose aligned.apk

返回jar verified表示v1签名校验通过。但要注意的是，jarsigner只操作v1签名，如果你用Android 7以上设备安装，系统默认还会要求v2签名。这时候用apksigner verify检查会提示“v2 signature missing”，所以jarsigner签完后，最好再用apksigner补签一次v2，或者干脆别用这条路。

我的个人习惯是：jarsigner只用于排查老设备兼容性问题，日常重签名一律用apksigner。

4.3 遇到旧签名文件残留时的处理

刚才说过，使用apksigner一般不需要手动删旧签名。但有几种特殊情况必须手工清理：

• 你要用jarsigner重签，但原包META-INF下有旧签名文件
• 原包曾被多次签名，包内已经有多套签名文件
• apksigner重签后verify报“Jar signer contains multiple signers”

处理办法是用zip命令或7-Zip删掉META-INF下的签名残留：

zip -d old-signed.apk "META-INF/*.RSA" zip -d old-signed.apk "META-INF/*.DSA" zip -d old-signed.apk "META-INF/*.EC" zip -d old-signed.apk "META-INF/*.SF"

删干净后再走zipalign和apksigner流程。注意，MANIFEST.MF也建议一并删掉，让apksigner重新生成：

zip -d old-signed.apk "META-INF/MANIFEST.MF"

不过我不建议对原包直接删，更稳妥的做法是先复制一份原包，在副本上操作。

5. 重签名后的验证与高频踩坑排查

命令能跑通只是第一步，很多问题都藏在签名之后的验证环节。这一节我把自己实际遇到过的坑按排查链路列出来，照着这个顺序检查，能解决大部分疑难杂症。

5.1 验证签名状态和证书指纹

重签完以后不要急着发出去，先用一条命令做全面体检：

apksigner verify -v --print-certs final-signed.apk

正常输出类似：

Verifies Verified using v1 scheme: true Verified using v2 scheme: true Verified using v3 scheme: true Signer #1 certificate DN: CN=... Signature algorithms: SHA256withRSA

重点看三处：

1. Verifies字段状态
2. v1/v2/v3哪些为true
3. 证书DN是不是你自己的信息

如果Verifies显示DOES NOT VERIFY，说明签名数据有问题，检查一下签名命令中的keystore和alias是否匹配。证书指纹用来给第三方SDK登记，拿到--print-certs输出的SHA-256那段，妥善保存。

5.2 安装报INSTALL_PARSE_FAILED与对齐警告

在真机上验证签名最直接的方式是安装：

adb install final-signed.apk

常见的报错有这么几类：

如果安装报错来自对齐问题，还有一个排查技巧：用zipalign检查验证：

zipalign -c -v 4 final-signed.apk

输出Verification succesful就说明对齐没问题。检查失败的话，需要重新对齐再签名，千万别在签名之后单独跑zipalign，那会让v2/v3签名失效。

5.3 第三SDK证书指纹校验失败

重签名最容易忽略的是第三方组件。很多推送SDK、统计SDK、地图SDK在初始化时会读取应用签名指纹并上报服务端校验，用于防止应用被仿冒。你把自己的APK重签名后，指纹必然变化，于是SDK初始化失败，表现通常是：

• 日志里出现signature check failed或fingerprint mismatch
• 推送收不到、支付结果回调异常、地图鉴权失败
• 功能可用但出现“该应用已被篡改”的提示

排查链路是这样：

1. 先定位SDK初始化代码里，是否调用了getPackageInfo拿签名做对比
2. 用apksigner verify --print-certs final-signed.apk拿到新指纹
3. 到SDK厂商的开放平台后台，把证书指纹登记信息改成新值
4. 重新初始化测试

这里有一个很多人都会踩的细节：后台登记指纹时，有的平台要求填MD5，有的要求填SHA-1，有的填SHA-256。而--print-certs默认可能只打印其中一部分。如果后台要求MD5，可以用keytool从keystore里直接读取：

keytool -list -v -keystore my-release.keystore -alias myalias

输出中会有MD5、SHA-1、SHA-256三套指纹，按需复制。别复制错格式，很多SDK鉴权失败都是因为把SHA-256贴到了MD5栏。

5.4 重签名后应用启动异常

签名本身不改变APK内的DEX和资源，正常情况下重签名后应用行为不会改变。但如果你遇到启动闪退，先不要怀疑是签名问题。按顺序排查：

• 检查App是否配置了Signature级别的自定义权限或组件保护，这类组件在签名变化后可能直接拒绝运行
• 检查是否有基于PackageManager做签名校验的应用内代码，比如一些加固的“防篡改”逻辑
• 检查META-INF目录下是否残留与旧签名相关的自定义校验文件

有一个真实案例：某开发者给APK做了重签名后，应用一启动就退出，日志里没有明显异常。最后查出来，应用内增加过一个“首次启动校验安装来源”的功能，主动检查安装包的签名证书DN是否与内置列表匹配。重签名后证书DN变了，校验失败直接自杀式退出。这不是签名流程的问题，而是业务代码对证书的强绑定，只有同步更新内置证书列表才能解决。

6. 落地之后的长期经验：签名管理与方案选择

重签名操作本身不难，难点在于长期维护。这里把几个容易被忽略的点单独拎出来说。

6.1 签名兼容性与算法配置

重签名时我建议统一使用SHA256withRSA或更高强度算法。不要为了兼容老系统去用SHA1withRSA，Android 8以上已经逐步取消对SHA-1的信任。apksigner默认会根据参数选择合理算法，不需要特别指定；jarsigner则必须显式加-sigalg SHA256withRSA -digestalg SHA-256。

如果你的APK还要兼容Android 6及以下设备，一定要保证v1签名启用。v1签名校验一次一个文件，安装时稍慢，但这是老设备唯一的凭证。用apksigner时直接用默认参数即可，它会根据--min-sdk-version来推导签名方案组合；不放心就显式写上：

apksigner sign \ --ks my-release.keystore \ --ks-key-alias myalias \ --v1-signing-enabled true \ --v2-signing-enabled true \ --v3-signing-enabled true \ --out final-signed.apk \ aligned.apk

多平台同时投递时，建议先把v1、v2、v3全部打开，宁可多签，不要少签。

6.2 密钥库管理规范

这次重签用的证书，一定记住三件事：备份、备份、备份。keystore文件本身要复制到至少两个不同的存储位置，密码记录在保密且可追溯的地方。我用过的项目里，有因为同事离职、密码交接不清，导致线上应用无法升级的；也有因为keystore被误传到网盘，导致应用证书泄露被冒签的。

建议把keystore文件和密码分开存放，权限控制在最小范围。如果团队配合，可以在CI/CD流水线中把keystore路径、密码配置为环境变量或专门的密钥管理服务，打包时自动消费，人少接触证书，出错概率自然低。

6.3 重签名的边界：别拿它做不合规的事

重签名是一种工程能力，但使用边界要心里有数。加固后重签自己的APK、企业定制化接管自家应用，都是常规操作。如果拿别人的应用（尤其是正式版商业应用）重签名后二次分发、去除广告、强行替换签名以绕过原有权限体系，这就不只是技术问题了，而是明确的侵权和违规行为。

Android系统把签名作为应用身份的根，重签带来的身份变更，会影响应用之间的信任关系。我之前经手过一个项目，两套应用原本通过签名实现单点登录，后来某次重签导致两边的签名证书不一致，互通功能直接瘫痪，最后只能用v3密钥轮换做证书迁移。所以重签名前，先想清楚这个更改会影响到哪些联动方，再动手。

最后说点我自己的实践体会

做过一轮又一轮重签名之后，我最大的感受是：这个问题不急的时候谁都懒得碰，一旦急着发布就会连环踩坑。把apksigner、zipalign这两个工具的用法刻进肌肉记忆，把“先对齐、再签名、最后verify”当成不可改变的顺序，大部分重签场景就不会翻车。

再分享一个压箱底的小技巧：重签名后的APK，在正式分发前用apksigner verify --print-certs的输出和上一个版本的输出做一次对比。如果上一版证书DN和指纹能查到，就把它存成基线文件，后续每次重签都对比一下，系统集成联调时可以少很多扯皮。签名这件事最好固化在打包脚本里，不要再靠手工点来点去，一旦自动化，重签就是流水线上最不起眼的一环了。