1. 项目概述：为什么我们需要重新签名APK？

在Android开发与逆向工程领域，给APK重新签名或者更改签名，是一项看似基础但至关重要的操作。你可能遇到过这些情况：从某个渠道下载的APK无法安装，提示“签名不一致”；或者你想对某个应用进行二次开发（比如汉化、去广告），修改了资源后必须用你自己的密钥重新签名才能安装；又或者，在团队协作中，你需要用公司的统一发布证书替换掉开发者的调试证书。这些场景的核心，都指向了APK签名机制——它是Android系统确认应用身份和完整性的基石。

简单来说，APK签名就像是一个应用的“数字指纹”和“防伪印章”。系统通过它来验证这个APK是否由可信的开发者发布，并且在发布后没有被任何人篡改过。一旦你对APK文件进行了任何修改（哪怕只是改了一个图标图片），原有的签名就会失效。这时，你就必须用自己的密钥对这个“新”的APK进行重新签名，才能让它被设备接受。这个过程不仅涉及jarsigner或apksigner这样的工具，更关系到密钥库（keystore）的管理、签名算法的选择，以及一系列容易踩坑的细节。接下来，我会结合多年的实操经验，为你拆解从原理到实践的完整步骤。

2. 核心原理与准备工作：理解密钥、证书与签名

在动手之前，我们必须搞清楚几个核心概念，这能帮你理解每一步操作背后的意义，而不是机械地敲命令。

2.1 密钥库（Keystore）与密钥对

Android的签名基于非对称加密。你需要一个密钥库文件（通常是.keystore或.jks格式），里面存储着一对密钥：私钥和公钥。

• 私钥：这是你的“绝密印章”，必须严格保密。用它来对APK进行签名。一旦丢失，你将永远无法用相同的“身份”更新你的应用。
• 公钥：由私钥衍生而出，可以公开。它会和开发者信息一起打包进APK的证书中。

当你使用keytool或Android Studio生成签名密钥时，实际上就是在创建一个新的密钥库和其中的密钥对。重新签名时，你可以使用全新的密钥库，也可以使用已有的。

注意：用于上架应用商店的发布密钥一旦生成，就必须妥善备份。因为Google Play等平台要求应用更新必须使用相同的证书签名。丢失它意味着你无法更新已上架的应用，只能以全新应用的身份重新发布。

2.2 签名流程与验证机制

签名过程可以简化为：开发者用私钥对APK的摘要信息（哈希值）进行加密，生成签名块，然后将这个签名块和对应的公钥证书一起放入APK的META-INF目录。安装时，系统会做两件事：

1. 完整性验证：用APK中的公钥解密签名，得到原始的摘要信息A。同时，系统会实时计算APK文件的摘要信息B。如果A等于B，说明APK自签名后未被篡改。
2. 身份验证：检查公钥证书是否受信（例如，是否与已安装应用证书一致，或是否为调试证书）。

重新签名，就是用你的私钥，对修改后的APK文件执行一遍上述的签名流程，用你的证书替换掉原来的证书。

2.3 工具选择：jarsigner vs apksigner

这是实际操作中的第一个关键选择。主要有两个工具：

• jarsigner：JDK自带的元老级工具，历史久远。它主要用于对JAR文件进行签名，早期Android也沿用此工具。它进行的是v1签名（JAR签名）。
• apksigner：Android SDK自带的官方工具，专为APK设计。它支持更现代的v2（APK签名方案V2）、v3、v4签名，提供了更强的安全性和性能。

如何选择？

• 如果你的目标设备系统版本广泛（尤其是需要兼容Android 6.0及以下），建议同时使用v1和v2签名。可以使用apksigner一次性完成。
• 如果你只是进行简单的重签名测试，使用jarsigner（仅v1）可能更快捷。
• 强烈建议：对于任何正式或需要良好兼容性的场景，使用apksigner进行v1+v2签名。这也是当前Android开发的默认和推荐做法。

准备工作清单：

1. 安装Java JDK：确保系统已安装JDK（8或以上版本），并配置好JAVA_HOME环境变量。keytool和jarsigner都包含在JDK中。
2. 安装Android SDK：至少需要SDK中的build-tools目录，因为apksigner工具就在其中（路径通常为$ANDROID_SDK_ROOT/build-tools/<版本>/apksigner.bat或apksigner.jar）。
3. 准备你的密钥库：如果你没有，需要创建一个；如果已有，请确保你知道别名（alias）和密码。
4. 准备待签名的APK文件：确保它是未签名或已去除原有签名的（“重打包”操作通常包含去签名步骤）。

3. 详细实操步骤：从零开始完成APK重签名

下面我将以最常用、最稳妥的apksigner（v1+v2签名）流程为主线，同时对比介绍jarsigner的方法。

3.1 步骤一：生成新的签名密钥库（如需要）

如果你还没有自己的密钥库，使用JDK的keytool命令生成一个。打开终端（Linux/macOS）或命令提示符/PowerShell（Windows）。

keytool -genkeypair -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias

逐项解释这个命令：

• -genkeypair：生成密钥对。
• -v：详细输出。
• -keystore my-release-key.jks：指定生成的密钥库文件名和格式（.jks是Java KeyStore的缩写，现在更常用）。
• -keyalg RSA：密钥算法，RSA是通用且受支持的选择。
• -keysize 2048：密钥长度，2048位是当前的安全标准。
• -validity 10000：证书有效期天数（约27年）。对于测试，可以设短些；对于发布，建议设置足够长。
• -alias my-alias：密钥的别名，一个密钥库可以存多个别名，用于区分不同用途的密钥。

执行后，会交互式地让你输入密钥库密码、密钥密码（可与库密码相同）、姓名、组织单位等信息。请务必记住密钥库路径、别名、两个密码，这是后续签名的关键。

3.2 步骤二：为APK移除旧签名（可选但推荐）

如果你要修改的是一个已经签名的APK（例如从网上下载的），直接对其重新签名可能会因为残留的旧签名文件而导致冲突或安装失败。一个干净的做法是先移除旧的签名文件。APK本质上是一个ZIP压缩包，签名信息存放在META-INF文件夹内。

方法A：使用解压缩工具手动删除（适用于简单操作）

1. 将your_app.apk重命名为your_app.zip。
2. 解压这个ZIP文件。
3. 删除解压后根目录下的META-INF文件夹。
4. 将剩余的所有文件重新压缩成一个新的ZIP文件。
5. 将这个新ZIP文件重命名为your_app_unsigned.apk。

方法B：使用命令行工具（更高效）在Linux/macOS上，可以使用zip命令：

zip -d your_app.apk 'META-INF/*'

这条命令会直接从APK（ZIP）文件中删除META-INF目录下的所有内容。

在Windows上，如果没有zip命令，可以使用7-Zip的文件管理器打开APK，直接删除META-INF目录后保存。

实操心得：对于从正规渠道（如Google Play）提取的APK，其签名有防篡改保护，直接删除META-INF后重签安装，可能会在运行时报签名校验错误（如果应用自身有校验逻辑）。这已超出系统安装验证的范畴，属于应用自身的加固或保护措施。

3.3 步骤三：使用apksigner进行V1+V2签名

这是目前Android官方推荐的标准流程。假设你的apksigner工具路径已加入环境变量，或者你已切换到其所在目录。

基本命令格式：

apksigner sign --ks [密钥库路径] --ks-key-alias [密钥别名] --out [输出APK路径] [待签名APK路径]

一个完整的签名示例：

apksigner sign --ks /path/to/my-release-key.jks --ks-key-alias my-alias --out app_resigned.apk app_unsigned.apk

执行后，会提示你输入密钥库密码和密钥密码（如果设置了不同的密码）。

关键参数详解：

• sign：执行签名操作。
• --ks：指定密钥库文件路径。
• --ks-key-alias：指定密钥库中用于签名的别名。
• --out：指定签名后输出的APK文件路径。如果不指定，默认会覆盖原文件（慎用）。
• --v1-signing-enabled true --v2-signing-enabled true：这是默认行为，即同时启用V1和V2签名。如果你想强制只使用某一种，可以显式设置为true/false。为了最大兼容性，保持两者都为true即可。
• --ks-pass和--key-pass：可以通过pass:前缀直接在命令中提供密码（如--ks-pass pass:123456），但出于安全考虑，不建议在脚本中明文写入密码，尤其是有版本控制的情况下。

3.4 步骤四：使用jarsigner进行V1签名（传统方法）

如果你因某些原因需要使用jarsigner，命令如下：

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore /path/to/my-release-key.keystore app_unsigned.apk my-alias

• -verbose：输出详细日志。
• -sigalg和-digestalg：指定签名算法和摘要算法。这里用的是较旧的组合，但兼容性最好。
• -keystore：指定密钥库。
• 最后是待签名APK和别名。

使用jarsigner签名后，必须执行一步优化对齐操作（使用zipalign工具，也在Android SDK的build-tools里），否则可能无法安装或运行效率低。

zipalign -v 4 app_signed_by_jarsigner.apk app_aligned_final.apk

-v 4表示4字节对齐，这是Android系统的要求。

3.5 步骤五：验证签名

签名完成后，务必验证签名是否成功且符合预期。

使用apksigner verify命令：

apksigner verify -v app_resigned.apk

-v参数会输出详细信息，你可以看到签名使用的算法（SHA256 with RSA）、证书哈希、以及是否启用了V1和V2方案。

使用keytool查看证书信息：

keytool -printcert -jarfile app_resigned.apk

这个命令会打印出APK中签名证书的详细信息，如所有者、发布者、有效期等，确认是否是你自己的证书。

4. 常见问题、排查技巧与高级场景

在实际操作中，你几乎一定会遇到各种问题。下面是我总结的“避坑指南”。

4.1 安装失败：INSTALL_PARSE_FAILED_NO_CERTIFICATES

问题描述：使用adb install安装重签名后的APK时，提示此错误。原因与排查：

1. 签名过程完全失败：APK内没有任何签名信息。用apksigner verify检查，会直接报错。回顾签名命令是否正确，密钥密码是否输入错误。
2. 仅使用了V2签名，且目标系统版本过低：Android 7.0 (Nougat) 以下系统不支持纯V2签名。确保签名时启用了V1方案（--v1-signing-enabled true）。
3. 使用jarsigner后未进行zipalign对齐。用zipalign -c 4 your.apk检查对齐情况。

4.2 安装失败：INSTALL_FAILED_UPDATE_INCOMPATIBLE 或 签名不一致

问题描述：设备上已安装了该应用的另一个版本（例如原版），安装重签名版时提示无法更新或不兼容。原因与解决： 这是最核心的签名机制在起作用。系统判定两个APK的签名证书不同，因此认为是两个完全不同的应用，不允许覆盖安装。

• 如果你想替换安装：必须先用adb uninstall或从设备设置中卸载原应用。
• 如果你想保留数据测试：只能修改重签名APK的包名（package name），这涉及到反编译、修改AndroidManifest.xml并重新编译，属于更复杂的“重打包”范畴，不是简单的重签名。

4.3 运行崩溃：Java.Security.SignatureException

问题描述：重签名后的APK能安装，但一打开就闪退，查看日志（adb logcat）可能发现签名校验相关的异常。原因：这是应用自身实施了签名校验。开发者在其Java代码中，通过PackageManager获取应用的签名哈希值，并与一个硬编码在代码中的正确值进行比较。如果不符合，则主动让应用崩溃，以防止应用被篡改。应对思路：这超出了系统签名的范畴，属于应用加固或保护。你需要进行逆向工程，定位并绕过校验代码。这需要一定的反编译（如使用jadx-gui）、代码分析甚至二进制修改的能力，是一个更深层次的课题。

4.4 针对Split APK（App Bundle产出的APK集）的重签名

从网络热词中看到这样的命令：adb install-multiple -r base.apk split_config.arm64_v8a.apk split_config.xxhdpi.apk这安装的是Android App Bundle（AAB）格式生成的拆分APK（Split APK）。对于这种多个APK文件的重签名，原则是：每一个.apk文件都需要单独用相同的密钥进行签名。 你不能把它们合并成一个APK再签，而是需要对base.apk、split_config.arm64_v8a.apk等每一个文件，都执行一遍上述的签名流程，使用完全相同的密钥库和别名。然后用adb install-multiple命令一起安装。

4.5 自动化脚本示例

如果你需要频繁进行重签名操作，编写一个简单的Shell脚本（Linux/macOS）或批处理脚本（Windows）会非常高效。

一个简单的Bash脚本示例 (resign.sh)：

#!/bin/bash # 配置变量 KEYSTORE_PATH="/path/to/your.keystore" KEY_ALIAS="your_alias" UNSIGNED_APK="$1" OUTPUT_APK="${UNSIGNED_APK%.*}_resigned.apk" # 检查输入 if [ -z "$UNSIGNED_APK" ]; then echo "用法: $0 <待签名的APK文件>" exit 1 fi # 执行签名 echo "正在为 $UNSIGNED_APK 重新签名..." apksigner sign --ks "$KEYSTORE_PATH" --ks-key-alias "$KEY_ALIAS" --out "$OUTPUT_APK" "$UNSIGNED_APK" # 验证签名 echo "验证签名结果..." apksigner verify -v "$OUTPUT_APK" if [ $? -eq 0 ]; then echo "重签名成功！输出文件: $OUTPUT_APK" else echo "重签名或验证失败！" fi

保存后，赋予执行权限chmod +x resign.sh，然后通过./resign.sh your_app.apk运行。

5. 工具链的安装与配置问题排查

很多新手卡在第一步——环境配置上。这里集中解答：

问题：keytool或jarsigner命令未找到？这说明JDK未正确安装或环境变量未配置。去Oracle官网或Adoptium等网站下载安装JDK，然后确保JAVA_HOME环境变量指向JDK安装目录，并将%JAVA_HOME%/bin（Windows）或$JAVA_HOME/bin（Linux/macOS）添加到系统的PATH变量中。

问题：apksigner命令未找到？apksigner是Android SDK Build-Tools的一部分。你需要通过Android Studio的SDK Manager下载特定版本的Build-Tools。安装后，其路径通常为$ANDROID_SDK_ROOT/build-tools/<版本号>/。将这个目录添加到系统的PATH变量中是最方便的做法。你也可以在命令行中直接使用完整路径来运行它。

问题：签名时提示“keystore was tampered with, or password was incorrect”？这明确表示密钥库密码错误。请仔细检查密码大小写和特殊字符。如果忘记密码，且没有备份，那么这个密钥库就无法再使用了，凸显了备份的重要性。

关于签名算法选择的深层建议：在apksigner中，默认使用的签名算法是强安全的（如SHA256 with RSA）。但在极少数非常古老的设备（Android 4.2以前）上，可能会因为系统缺失相应的加密算法支持而导致安装失败。如果你需要兼容这种“古董”设备，可以考虑在jarsigner中使用-sigalg SHA1withRSA -digestalg SHA1这种较弱的算法组合，但必须清楚这降低了安全性。在当今移动环境下，这种需求已非常罕见。