APK 内 Native 库的打包对齐怎样验收：ZIP、ELF、ABI 与签名顺序

先拆开三种容易混淆的对齐问题

Native 库进入 APK 后同时存在三层结构。最外层是 ZIP 容器，决定未压缩条目的数据从哪个文件偏移开始；中间是 lib/<abi>/ 目录，决定安装器和运行时把库归到哪个 ABI；最内层是 ELF 文件，program header 里的 PT_LOAD 段决定加载映射所需的对齐。三层都叫“对齐”或“兼容”，但失败原因、检查工具和修复位置完全不同。

只执行 zipalign 能发现 APK 容器内的偏移问题，却不会重写已经链接好的 ELF program header。反过来，readelf 显示 LOAD 段满足要求，也不代表该 SO 在签名后的 APK 中位于正确偏移，更不代表它被放进正确 ABI 目录。验收报告必须按层记录观察值，不能把一条笼统的“Native 对齐通过”覆盖所有风险。

最终结论还需要设备交付和运行证据。AAB 会按设备配置派生 base、ABI、语言和密度相关 APK，测试人员在本地看到的通用 APK 不一定等于用户收到的组合。静态检查负责证明候选字节的结构；派生 APK 检查负责证明交付集合；目标设备安装、启动和 Native 入口回归负责证明运行行为。

以最终 APK 建立 Native 库清单

Native 清单应从最终 APK 读取，而不是从源码仓库、CMake 输出目录或 Gradle 中间目录推断。应用可能引入预编译 AAR、按 ABI 拆分的第三方 SDK、构建变体专用库和后处理生成的桥接库；最终合并、剔除或重命名后，实际文件集合可能与任何单一模块目录不同。每个条目至少记录 APK 路径、ABI、压缩方式、未压缩大小、CRC、数据偏移和内容摘要。

Android NDK 文档定义了 Android 支持的 ABI 及其调用约定、寄存器和数据布局。目录名是安装器识别架构的契约，不是随意标签。把某个架构的 ELF 放入另一 ABI 目录，即使文件名相同也不能视为兼容。检查器应同时读取目录 ABI 和 ELF header 的机器类型；本文示例聚焦目录、ZIP 与 LOAD 对齐，机器类型交叉核对仍应进入项目完整门禁。

清单还要标明库来源。自研库可以回到链接参数和工具链修复，第三方预编译库则需要向供应方索取兼容版本或重新构建许可。若多个 AAR 带入同名 SO，构建系统的选择规则可能隐藏其中一个版本。只检查最后被选中的文件可以判断候选结构，但无法解释依赖冲突，发布证据应保留依赖来源和决策记录。

正确解释 ZIP 条目对齐与压缩方式

zipalign 调整的是 ZIP 内未压缩数据的起始位置，使安装或运行时可以按合适边界直接访问。真正的数据偏移不是 central directory 中记录的 header_offset 本身，而是 local file header 之后再加文件名和 extra field 的长度。自制检查器若只对 header_offset 取模，可能给出错误结论。应解析 local header 并对实际 data_offset 计算。

Native 库是否压缩会改变装载路径。未压缩 SO 可以从 APK 直接映射时，数据偏移需要满足相应边界；压缩 SO 通常需要在安装期间提取，验收重点会转向提取策略、磁盘产物与安装行为。不能看到压缩条目就机械宣称失败，也不能用压缩绕开页面尺寸兼容要求，因为 ELF 自身的 LOAD 段仍必须符合目标运行环境。

Android 的 zipalign 文档强调在 apksigner 之前完成对齐，并提供校验模式检查现有 APK。构建流水线应保存工具版本、完整命令、候选摘要和校验输出。工具返回成功只证明它覆盖的对齐条件，不证明 APK 签名、ABI 组合、ELF 链接参数或目标设备运行通过，报告中应保留这条边界。

• 从 local file header 计算真实数据起始偏移
• 分别记录 ZIP_STORED 与压缩条目
• 未压缩 SO 使用适合目标页尺寸的校验参数
• 对齐动作只发生在 apksigner 之前
• 签名后的 APK 只执行只读校验
• 保存 zipalign 版本、参数、输出和 APK 摘要
• 对齐通过不扩大为 ELF 或设备兼容通过

用 ELF program header 检查 LOAD 段

ELF 对齐由链接阶段决定。readelf 可以展示 ELF header、program header、dynamic section、符号、重定位和展开信息；针对页面尺寸，首要观察每个 PT_LOAD 段的 Offset、VirtAddr 和 Align。p_align 表示段在文件与内存中的对齐约束，文件偏移与虚拟地址还应满足 ELF 规定的同余关系。仅检查 section header 或文件整体大小不能代替 program header。

Android 的 16 KB 页面尺寸指南要求团队同时核对 Native 构建、预编译库、APK 打包和目标设备测试。静态脚本可以筛出 p_align 小于目标值的 LOAD 段，并列出来源库，但不能自动修复。自研库需要调整链接器和构建工具链后重新生成；预编译库需要获取兼容版本。把旧 SO 外层重新 zipalign 不会改变内部段对齐。

静态通过仍不是运行通过。动态链接还依赖 DT_NEEDED 依赖、符号版本、重定位、加载顺序、JNI 注册和系统 API 可用性。readelf 的字段存在只说明候选具备相应结构，不能证明 System.loadLibrary、进程启动或异常传播成功。设备回归至少要覆盖安装、冷启动、首次 Native 装载和一条真实业务调用，并绑定同一 APK 摘要。

从 AAB 派生 APK 复核真实 ABI 交付

AAB 不是直接安装到设备的单一 APK。Build and test Android App Bundles 文档说明可以使用 bundletool 构建 APK set、按设备规格生成或选择 APK 并执行测试。Native 对齐验收应从发布候选 AAB 派生代表性设备的 APK 集，再对包含 lib 目录的 base 或 ABI split 分别执行清单、ZIP、ELF 和签名检查。只检查 AAB 内部文件布局不足以代表最终交付。

设备规格要与支持矩阵对应。至少按产品实际支持的 ABI、系统版本和页面尺寸路径选取代表性组合，并保存设备规格文件、bundletool 版本、输入 AAB 摘要与输出 APK set 摘要。若使用 universal APK 做快速检查，要明确它属于支持性证据；真实设备可能收到拆分后的不同文件集合，不能把 universal 结果直接登记为所有设备交付通过。

本地派生也不能完全替代商店。应用签名密钥、商店处理、交付规则和测试轨道可能改变最终候选身份或组合。合理的证据分级是：本地 APK 结构检查、发布签名候选检查、测试轨道交付回执和目标设备运行分别登记。缺少线上回执时可以说本地派生门禁通过，但不能写成生产用户已经收到同一字节。

把 zipalign、apksigner 和归档顺序固定下来

APK 签名覆盖候选字节，对齐或重新打包会改变 ZIP 结构。apksigner 文档明确要求签名后不要继续修改 APK；因此流水线顺序应固定为构建、对齐、签名、签名验证、只读结构检查和归档。若签名后的 zipalign 校验失败，正确动作是回到签名前产物重新对齐并再次签名，而不是直接修改已经签名的候选。

签名验证至少要记录使用的签名方案、证书摘要、工具版本和验证结果，并与最终 APK 的 SHA-256 摘要绑定。apksigner 验证成功只说明该 APK 的签名结构在工具覆盖范围内有效，不证明 keystore 托管、签名权限、渠道上传或候选归档流程正确。商业发布还需要独立的签名材料管理和操作审计。

归档时应把 APK、AAB、APK set、SO 清单、zipalign 输出、readelf 摘要、apksigner 输出和设备回执关联到同一 release_id。任何重新签名、重新压缩、渠道处理或依赖替换都会生成新身份，旧证据不能复制。自动化可以用摘要阻止错配，但最终状态必须由全部门禁共同决定，不能因为最后一条命令退出码为零就标记发布通过。

• 构建后先完成 ZIP 对齐再执行 APK 签名
• 签名后的候选禁止任何字节级修改
• apksigner 验证结果绑定最终 APK 摘要
• 证书身份和签名方案进入发布记录
• 重新签名或重新打包后所有结构门禁重跑
• APK、AAB、APK set 与 SO 清单共享 release_id
• 命令成功与发布语义通过分别记录

用只读脚本同时检查路径、ZIP 与 ELF

下面的 Python 示例读取指定 APK，枚举 lib/<abi>/*.so，拒绝未知 ABI 目录和压缩 Native 条目，解析 local header 得到真实数据偏移，并从 ELF program header 提取每个 PT_LOAD 段的 p_align。只要任一输入派生条件不满足，就以非零状态退出。脚本不会修改 APK，适合在签名后作为补充门禁。

示例将未压缩 SO 的数据偏移和 LOAD 段对齐目标设为 16384 字节，服务于 16 KB 页面尺寸检查。项目如果同时支持其他打包策略，应把压缩库、提取行为和页尺寸要求拆成显式配置，不要直接删除判断。脚本也没有执行 zipalign 或 apksigner，官方工具输出仍应独立保存并与同一 APK 摘要绑定。

代码只处理小端 ELF32 与 ELF64 的基础 program header，不检查 machine、DT_NEEDED、符号版本、重定位或 JNI 行为。生产门禁应继续调用 readelf 获取完整静态记录，并在目标设备验证安装、加载和业务入口。公开示例没有包名、私有路径、证书或密钥，不能被当成任何具体候选已经通过的回执。

#!/usr/bin/env python3
import re
import struct
import sys
import zipfile
from pathlib import Path

ABI_PATH = re.compile(r"^lib/(arm64-v8a|armeabi-v7a|x86|x86_64)/[^/]+[.]so$")
TARGET_ALIGNMENT = 16384
PT_LOAD = 1

def data_offset(apk_file, info):
    apk_file.seek(info.header_offset)
    header = apk_file.read(30)
    if len(header) != 30:
        raise SystemExit(3)
    values = struct.unpack("<IHHHHHIIIHH", header)
    if values[0] != 0x04034B50:
        raise SystemExit(4)
    name_length, extra_length = values[-2], values[-1]
    return info.header_offset + 30 + name_length + extra_length

def load_alignments(blob):
    if blob[:4] != b"\x7fELF" or len(blob) < 64:
        raise SystemExit(5)
    elf_class, byte_order = blob[4], blob[5]
    if byte_order != 1:
        raise SystemExit(6)
    if elf_class == 1:
        ph_offset = struct.unpack_from("<I", blob, 28)[0]
        ph_size = struct.unpack_from("<H", blob, 42)[0]
        ph_count = struct.unpack_from("<H", blob, 44)[0]
        align_offset = 28
    elif elf_class == 2:
        ph_offset = struct.unpack_from("<Q", blob, 32)[0]
        ph_size = struct.unpack_from("<H", blob, 54)[0]
        ph_count = struct.unpack_from("<H", blob, 56)[0]
        align_offset = 48
    else:
        raise SystemExit(7)
    alignments = []
    for index in range(ph_count):
        offset = ph_offset + index * ph_size
        if offset + ph_size > len(blob):
            raise SystemExit(8)
        segment_type = struct.unpack_from("<I", blob, offset)[0]
        if segment_type == PT_LOAD:
            format_code = "<I" if elf_class == 1 else "<Q"
            alignments.append(struct.unpack_from(format_code, blob, offset + align_offset)[0])
    if not alignments:
        raise SystemExit(9)
    return alignments

def validate(apk_path):
    failures = []
    with apk_path.open("rb") as apk_file, zipfile.ZipFile(apk_path) as archive:
        libraries = [item for item in archive.infolist() if item.filename.endswith(".so")]
        if not libraries:
            raise SystemExit(10)
        for info in libraries:
            if not ABI_PATH.fullmatch(info.filename):
                failures.append(info.filename + ": invalid ABI path")
                continue
            if info.compress_type != zipfile.ZIP_STORED:
                failures.append(info.filename + ": compressed entry")
                continue
            offset = data_offset(apk_file, info)
            if offset % TARGET_ALIGNMENT != 0:
                failures.append(info.filename + ": ZIP offset not aligned")
            blob = archive.read(info)
            alignments = load_alignments(blob)
            if any(value < TARGET_ALIGNMENT for value in alignments):
                failures.append(info.filename + ": ELF LOAD alignment too small")
    if failures:
        for failure in failures:
            print(failure, file=sys.stderr)
        raise SystemExit(11)

def main():
    if len(sys.argv) != 2:
        print("Usage: apk_native_alignment.py APK_FILE", file=sys.stderr)
        raise SystemExit(2)
    apk_path = Path(sys.argv[1])
    if not apk_path.is_file():
        print("APK file not found", file=sys.stderr)
        raise SystemExit(2)
    validate(apk_path)
    print("native packaging alignment accepted")

if __name__ == "__main__":
    main()

用同一候选的证据矩阵决定是否发布

验收包应先固定 release_id、APK 摘要、版本、签名证书和目标 ABI，再收集 SO 清单。每个库都有 ZIP 压缩方式与数据偏移、ELF class、machine、PT_LOAD 对齐、依赖来源和摘要。随后对 AAB 派生 APK、apksigner 验证和设备回归建立引用。只有这些记录全部指向同一候选，才能避免把中间包的对齐结果贴到发布包。

负向用例应验证门禁真的会失败。可以准备公开安全的测试产物，分别放入未知 ABI 目录、改变 ZIP 偏移、使用较小 LOAD 对齐、在签名后修改条目或从设备规格中选择不同 ABI，确认对应检查在预期层拒绝。负向样本不需要包含业务库或真实证书，报告只保留失败类别、观察位置和修复责任。

当前没有具体 APK、AAB、SO、签名回执和设备运行记录，因此本文只能提供结构化方法与检查代码，不能断言某个候选已经支持 16 KB 页面、通过商店交付或完成兼容验收。项目实施时，任何库、工具链、压缩策略、签名身份或派生规则变化都应触发重新检查，并明确尚未覆盖的 ABI 与设备范围。