zipalign 为什么必须放在 APK 签名之前：字节变化、签名失效与流水线顺序

对齐与签名的根本冲突：字节修改即破坏

APK 文件本质是一个 ZIP 压缩包，内含 DEX 字节码、资源文件与原生库等。ZIP 格式通过局部文件头与位于文件尾的中央目录记录每个条目的偏移量和长度。当执行 zipalign 对齐时，工具会重新排列各条目，必要时插入填充字节，以确保所有未压缩数据的起始地址对齐到 4 字节边界。这一处理必然修改局部文件头的偏移字段和中央目录的记录，导致整个 APK 的字节序列发生实质变化。

数字签名保障 APK 完整性的机制基于哈希：签名生成时，对 APK 文件的规定区域依据签名方案版本计算摘要，并以签名者私钥加密该摘要形成签名块。验证过程重新计算摘要并与解密后的签名摘要比对，任何字节差异都会导致摘要不匹配，即使修改仅发生在偏移量上。由此，签名后的任何字节级变动，包括对齐引起的重排，都将使签名失效。

Android 系统在安装和更新应用时强制进行签名验证。PackageManager 会解析所有签名方案对应的签名块并校验内容摘要，一旦失败即返回类似 INSTALL_PARSE_FAILED_NO_CERTIFICATES 或 INSTALL_FAILED_INVALID_APK 的错误。Google Play 在内的各个应用商店同样在预检阶段执行严格的完整性校验，未通过的包会被直接拒绝。因此对齐必须在签名前完成，否则签名会失效，APK 无法安装。

zipalign 的运作机制与破坏签名的原理

zipalign 是 Android SDK Build-Tools 中的官方工具，主要目的是优化 APK 内存映射访问性能。它强制所有未压缩文件的数据偏移对齐到 4 字节边界，减少系统在 mmap 进行内存访问时的页面调度开销。对齐过程中，zipalign 先读取 APK 的全部 ZIP 条目，计算出新的排列顺序，必要时在条目之间填充空字节，然后重写整个 ZIP，更新局部文件头偏移和中央目录偏移。文件总长度及中央目录位置因此改变。

若在签名后再次运行 zipalign，工具仍执行相同的重排和填充过程。对于 v1 JAR 签名，签名文件 CERT.SF 中按顺序记录每个条目的摘要，条目顺序改变后 MANIFEST.MF 中的摘要次序也会发生变化，使得签名文件中的摘要与重新计算的不同，验证失败。对于 v2/v3 签名，其 APK Signing Block 保护 ZIP 内容及中央目录，但不覆盖签名块自身；对齐导致的中央目录和条目偏移重写会完全破坏签名块锁定的内容摘要，签名必然失败。

即便对齐操作仅涉及资源文件间的填充，而未修改 DEX 或原生库的字节内容，ZIP 格式的整体结构已经改变。签名保护的是从文件起始到签名块之前的所有字节，对齐引入的任何一处偏移改动都会传导为重新计算的摘要与签名块中存储的摘要不同，而不存在局部可恢复的可能性。因此，zipalign 必须在开始签名流程前彻底完成，不得有任何形式的签名后对齐。

APK 签名方案的完整性保护与对齐约束

APK 签名从 v1 到 v4 逐步演进，但其完整性判定始终要求签名后文件不得有任何修改。v1 方案通过 META-INF 下的 MANIFEST.MF、CERT.SF 和 CERT.RSA 实现，其中 CERT.SF 按顺序包含所有条目的摘要；当对齐改变条目排列时，CERT.SF 中预期的摘要序列与文件新序列不再吻合。这也意味着即使 v1 方案未显式保护中央目录，它的顺序依赖已经足够被对齐打破。

v2 方案将签名信息置于 APK Signing Block 中，该区块位于 ZIP 中央目录之前。签名生成时对整个 APK 的 1 至 N 个块进行分区摘要并签名，覆盖中央目录与全部 ZIP 条目，只有签名块自身被排除。这一设计虽然解决了 v1 的签名块体积问题，但同时也将对文件任何部分的修改都转成致命的校验失败，对齐造成的中央目录重排通常会导致验证报错。

v3 方案在 v2 基础上增加密钥轮转能力，但内容保护范围不变，对齐依然会导致签名失效。v4 通过外部 .idsig 文件提供增量验证，它不能替代 v2/v3 的存在，APK 本身仍需通过主签名方案的验证。因此对于仍在维护的构建流水线，无论采用何种组合，对齐操作都必须排在所有签名操作之前，否则安装与上架都会直接报错。

• 确认项目签名方案覆盖 v1+v2 或 v2+v3，未遗漏关键签名块。
• 构建过程中在签名前不得加入任何改变 ZIP 结构的命令。
• 检查构建脚本中 zipalign 与 apksigner 的调用顺序是否严格固定。
• 验证 CI 流水线中是否有步骤会在签名后意外触碰 APK 文件。

签名后对齐导致的典型失败模式与诊断输出

当构建流水线错误地将 zipalign 置于签名之后，所生成的 APK 在安装时会立刻暴露问题。通过 adb install 安装，系统会在 logcat 中输出 Package … has no certificates 或 Signature check failed，说明签名构件无法通过验证。这类错误直接引导开发者反思签名完整性问题，是定位顺序错误的直观起点。

使用 apksigner verify --verbose 检查错误 APK 时，输出通常会包含 DOES NOT VERIFY 和具体的失败原因，如 v1 方案的 digest mismatch 或 v2 方案的 data signature did not verify。这些信息明确指出签名验证在哪个方案上折戟，并且与用户安装错误相互印证，极大概率表明签名后对齐导致了文件结构变动。

错误顺序产生的 APK 在上传应用市场时也无法通过前置校验。Google Play Console 的预上传检查会拒绝签名无效的包，并指示 APK 未通过完整性验证。这类拦截虽避免了失效包流入终端，但也让团队只能回退到流水线查找根因。如果组织缺少对齐与签名顺序的显式控制与日志记录，排查过程会显著延长。

构建流水线的正确 align-sign-verify 顺序与证据保证

正确的官方构建顺序为：生成未签名的 APK，代码混淆、资源压缩，移除无用资源，字节对齐 zipalign，应用签名 apksigner，对齐验证 zipalign -c，签名验证 apksigner verify，最后归档。只有在对齐后立即进行签名，且签名操作本身不改变对齐结构，最终的 APK 才能同时通过两项检查。

自动化构建脚本中应当实现严格的错误中断：zipalign 步骤执行后立即检查退出码，若不为零则终止整个流水线，避免未对齐的包进入签名；apksigner 步骤之后运行 verify 并检查退出码，连同日志一并保存。所有步骤之间不允许出现无人为干预的文件修改操作，避免因缓存或复制导致的间接改动。

建议团队保存每个候选包的 zipalign 检查输出、apksigner 验证结果和构建参数，并与产物摘要绑定。安装失败时，先确认最终 APK 是否来自“对齐后签名”的步骤，再核对证书与方案输出。这些记录是区分流水线错序和证书问题的必要依据，但不能代替实际验证。

对齐与签名校验工具的协同使用与各自局限

zipalign -c 提供纯粹的 ZIP 对齐检查，遍历 APK 中所有未压缩条目并验证其偏移是否符合指定对齐粒度。它完全无视 APK 中的任何签名数据，因此对齐检查通过绝不表示签名有效。正因如此，在签名后进行对齐错误的诊断时，绝不能仅凭 zipalign -c 来推断签名状态。

apksigner verify 是验证签名完整性的专门工具，它会解析 v1/v2/v3 等方案，并对比摘要。如果 APK 仅在签名前完成了正确的对齐，但签名后在传递过程中被无签名意识的过程重写了 ZIP，例如通过 zip 工具重新打包，签名同样会失效。因此，apksigner verify 通过也不能证明对齐仍然保持，两个工具必须配合使用。

对于流水线可疑产物的调查，需要将两个工具的输出结合起来：apksigner verify 通过但 zipalign -c 失败，说明签名前未对齐或对齐参数错误；zipalign -c 通过但 apksigner verify 失败，几乎就是签名后对齐或文件后期被修改的明确证据。两项皆通过才表明构建顺序正确，且产物未在后续传递中被意外破坏。任何一项失败都应当在发布前阻断。

#!/bin/bash
# check_align_sign.sh ， 诊断 APK 的 align-sign 顺序
# 用法：./check_align_sign.sh <APK 文件>

set -euo pipefail

APK="${1:?用法：$0 <APK 文件>}"

# 检查工具是否存在
if ! command -v zipalign &> /dev/null; then
    echo "错误：找不到 zipalign，请安装 Android SDK Build-Tools。" >&2
    exit 3
fi
if ! command -v apksigner &> /dev/null; then
    echo "错误：找不到 apksigner，请安装 Android SDK Build-Tools。" >&2
    exit 3
fi
if [ ! -f "$APK" ]; then
    echo "错误：文件 $APK 不存在。" >&2
    exit 3
fi

ALIGN_RESULT=0
SIGN_RESULT=0

# 对齐检查
echo ">>> 执行对齐检查 (zipalign -c -p 4)"
if ! zipalign -c -p 4 "$APK"; then
    ALIGN_RESULT=1
    echo "对齐检查：失败" >&2
else
    echo "对齐检查：通过"
fi

# 签名验证
echo ">>> 执行签名验证 (apksigner verify --verbose)"
if apksigner verify --verbose "$APK" &> /tmp/apksigner_verify_$$.log; then
    SIGN_RESULT=0
    echo "签名验证：通过"
else
    SIGN_RESULT=1
    echo "签名验证：失败" >&2
    grep -E "DOES NOT VERIFY|ERROR" /tmp/apksigner_verify_$$.log >&2 || true
fi
rm -f /tmp/apksigner_verify_$$.log

# 综合判断
if [ $ALIGN_RESULT -eq 0 ] && [ $SIGN_RESULT -eq 0 ]; then
    echo "结论：APK 对齐与签名均通过，顺序可能正确。"
    exit 0
elif [ $ALIGN_RESULT -ne 0 ] && [ $SIGN_RESULT -eq 0 ]; then
    echo "警告：APK 对齐失败但签名通过，可能签名前未执行对齐。"
    exit 1
elif [ $SIGN_RESULT -ne 0 ]; then
    echo "错误：APK 签名验证失败，极可能签名顺序错乱或文件损坏。"
    exit 2
else
    echo "未知状态。" >&2
    exit 3
fi

实战：诊断顺序错误并加固构建防线

为了快速判断任意 APK 是否遵循了先对齐后签名的顺序，可以编写只读诊断脚本。脚本接收 APK 路径，依次运行 zipalign -c 和 apksigner verify，综合二者的退出码和输出给出判定：双通过、对齐失败但签名通过、签名失败等。此类脚本可集成到 CI 流水线，阻止不安全产物进入分发环节。

诊断脚本的关键在于，失败判断必须基于实时读取的命令输出和退出码，不可依赖硬编码的预期值。例如，检查签名失败时应抓取 apksigner verify 输出中的 DOES NOT VERIFY 或 ERROR 字符串，并对不存在工具的情况立即报错退出，保证误判不会发生。脚本全程只读，不修改 APK，确保诊断本身不改变被检产物。

一旦诊断发现签名后对齐等不可修复状态，纠正的唯一可行路径是回到未签名且未对齐的原始 APK，重新执行对齐与签名。如果原始中间产物已经丢失，只能从源码重新编译。这要求团队在构建流水线中妥善保留对齐后未签名的工件，以降低返工成本，并避免采用任何试图在已签名 APK 上重新对齐的危险操作。

App Bundle 到 APK 的变换与对齐签名一致性的维护

Android App Bundle 作为发布格式，最终需通过 Google Play 或 bundletool 生成设备专属的切割 APK。在该变换中，对齐与签名顺序仍然适用。bundletool build-apks 若同时传递 --ks 选项签名，其内部处理会先对齐后签名。如果开发者选择生成未签名 APK 再手动签名，则必须手动确保对齐在前、签名在后。

自定义构建流水线有时会使用插件在 bundletool 输出后对 APK 做额外处理，例如压缩或删减文件，然后再执行签名。此类操作若稍有不慎，就可能破坏已有对齐或错误地倒置顺序。为此，建议在一次构建中一次性完成对齐与签名，并在签名后立即对全部输出 APK 使用诊断脚本进行批量的对齐与签名验证。

采用 Play App Signing 时，上传包仅用上传密钥签名，Play 后台则用应用签名密钥重签名。但即便在这一流程下，上传到 Play 的 APK 也必须在上传签名前完成对齐，否则 Play 在上传预检时就会因签名无效而拒绝该包。因此从开发者本地到最终分发，先行对齐的刚性约束贯穿始终。