Android 本地 AI 应用的 16 KB 页面对齐测试

直接回答

Android 本地 AI 应用的 16 KB 页面大小检查，必须覆盖最终安装包里的所有原生依赖，而不能只看 Kotlin 源码或最外层的运行时名称。Android 15 及后续版本可以运行在配置为 16 KB 内存页的设备上。Android 官方指南指出，如果应用或任意依赖包含原生代码，就应检查原生库、ELF 段对齐、安装包 ZIP 对齐，并在 16 KB 环境中测试行为。即使团队自己没有写 C/C++，机器学习运行时也可能通过依赖打包共享对象。首先固定准确的、接近发布的 APK，或固定 release bundle 生成的设备定向 APK。APK Analyzer 可以查看是否存在 lib 目录、包含哪些 ABI，以及打包的 .so 文件是否有对齐警告。AAB 并不等同于用户最终安装的设备定向 APK；应检查真实安装路径会交付的制品，或检查本次测试流程生成的 APK。记录安装包和库文件的提交及摘要，以便之后重现。分别检查每个原生库的 ELF LOAD 段对齐和 APK 中未压缩共享库的 ZIP 对齐；任何一项通过都不能代替其他检查。还要检查是否存在 GNU_RELRO 段；如果存在，按官方公式计算 `(VirtAddr + MemSiz) % 0x4000`，余数为零才通过该 RELRO 边界检查。Android 指出，NDK r27 及更低版本在未启用相关链接器标志时可能生成未对齐的 RELRO 段；不能仅凭版本标签推断某个依赖实际状态。针对准确制品使用官方 APK Analyzer、ELF、RELRO 和 zipalign 检查，不要从 AGP 设置、仍用 4 KB 页面的模拟器或 NDK 版本字符串推断兼容。随后在 Android 文档支持的 16 KB 配置中运行制品，例如对应模拟器系统镜像或官方说明的设备模式。运行应用前先核实环境；官方指南使用 `getconf PAGE_SIZE`，16 KB 测试环境应报告 16384。该值只证明测试环境，不是设备兼容清单。完整覆盖本地 AI 用户路径：干净安装、定位并验证模型文件、初始化运行时、执行固定且安全的样例。通过实际解析到的运行时 API 请求取消，等待该请求对应的原生终态回调，并确认没有任务仍在进行中。只有当解析后的 API 支持关闭且当前资源所有者有权关闭时，才关闭运行时；随后按需新建或重新打开会话，再运行同一固定样例。仅发出取消请求或改变 UI 状态，不能证明原生工作已停止。分别记录安装失败、链接器错误、模型解析错误、后端初始化、任务结果、回退、内存错误和恢复情况。有些应用可能进入针对 4 KB 的兼容模式；它不等同于已经验证的 16 KB 构建，因此在官方允许的范围内，应关闭兼容模式重新测试，并明确记录测试模式。不能由此发布模型速度、内存、电池、广泛手机支持或“NPU 兼容”结论。Cove 尚无完整真实设备基准数据集，因此本文提供页大小对齐和用户任务的测试方式，而非 Cove 设备通过名单。内部报告应包含应用版本与提交、依赖和运行时版本、准确 APK/AAB 与生成 split、ABI、全部原生库身份、ELF/RELRO/ZIP 对齐报告、操作系统构建及页大小证据、兼容配置、模型版本、样例、结果和失败日志。若某个依赖不透明或未被检查，应把矩阵标为未完整，而不能假定兼容。更新运行时、原生库、构建工具、打包设置、模型加载器或发布制品后，都应重新检查。任何正确结论都只适用于实际检查过的包与环境。测试步骤是：盘点最终安装包、检查每个原生二进制的 LOAD 段和 GNU_RELRO（如存在）、检查 APK ZIP 对齐、在选定 16 KB 环境安装、核实系统页大小、运行代表性推理生命周期、保存所有失败和恢复情况，最后只报告本次测试范围。对齐检查通过不等于运行时或任务兼容。这是一套兼容性验证方法，不是 Cove 实测成绩或认证。

本地模型在 4 KB 模拟器能启动，但发布包需要检查 16 KB

开发者的端侧 AI 应用构建成功，并在默认模拟器运行过一个测试。release bundle 带有第三方原生推理依赖，团队还未检查设备定向 APK，也未在 16 KB 页环境执行模型工作流。

决策

固定 release 包和原生库清单，执行官方对齐检查，再在有记录的 16 KB 环境测试安装、加载、推理、等待取消终态、确认没有进行中任务后按所有权关闭，以及恢复。

预期结果

团队能准确说出测试了哪个安装包和任务；若仍有库、split 或运行时路径未经验证，则继续把兼容结论标为未知。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• 准确 release 包与设备定向 split
• 每个 .so 的 ELF LOAD、GNU_RELRO（如存在）和 ZIP 对齐记录
• 16 KB 环境及完整推理生命周期结果

发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。

实施流程

1. 固定待测安装包. 记录应用提交、release 变体、运行时依赖、模型制品、bundle、生成的 APK split 和 ABI 列表。不能用 debug APK 替代 release 制品。
2. 盘点所有输出中的原生代码. 对实际交付路径生成的 APK 使用 APK Analyzer，识别所有 .so 文件、ABI 目录、库名和对齐警告，包括传递依赖中的运行时库。
3. 检查 LOAD、RELRO 与 ZIP 对齐. 对每个原生库运行文档提供的 ELF LOAD 段检查，并对最终 APK 执行 zipalign。使用 llvm-readelf -Wl 检查是否存在 GNU_RELRO；如存在，验证 (VirtAddr + MemSiz) % 0x4000 == 0。保存原始输出并关联到准确制品；任何一层通过都不证明其他层通过。
4. 核实 16 KB 测试环境. 使用 Android 平台文档描述的模拟器或设备配置。先确认环境报告 16 KB 页大小，并记录是否启用了兼容模式。
5. 运行完整推理生命周期. 安装准确制品，打开指定模型并运行固定且不含敏感数据的样例。使用解析后的运行时 API 请求取消，等待匹配请求的终态回调并确认没有任务仍在进行中；仅当解析后的 API 与资源所有权允许时才关闭，然后在新建或重新打开的会话中复跑样例。分别记录链接器、加载、任务和恢复问题。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 受测制品身份覆盖准确 release 文件、全部相关设备 split 和原生库。
• 分别记录每个原生库的 ELF LOAD 段和（如存在）GNU_RELRO 检查，以及最终 APK 的 ZIP 对齐结果。
• 解释应用行为前，测试记录证明环境页大小并说明兼容模式状态。
• 发布表述仅限实际测试的构建、运行时、ABI、环境和任务，不从结果推导普遍兼容或性能结论。

决策对照表

需要避免的失败模式

• 只检查应用自有代码
• 把 4 KB emulator 通过说成 16 KB 兼容
• 忽略第三方运行时原生库

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• Cove 基准测试方法
• Android Developers — 支持 16 KB 页面大小
• Android Studio — 使用 APK Analyzer 检查构建
• Android NDK — ABI 管理

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题