直接回答
Android App Bundle 是发布制品，不是直接安装到设备上的安装包。Android 官方 bundletool 文档说明，AAB 会被转换成适配设备配置的 APK，其中包括 ABI 配置 APK；bundletool 也能为本地测试重建并安装设备定向 APK set。因此，只检查通用调试 APK 或源码目录，不能证明某个设备安装的版本含有应用所需原生运行时库。应针对准确设备配置测试生成并安装的 split 集合。 从接近发布的已签名 bundle 开始，记录构建变体、应用版本、声明 ABI、直接依赖所需原生库，以及任何运行时可选库配置。为连接设备或保存的设备规格生成 APK set；检查归档与实际安装包内容，而不是假设另一设备的输出也代表当前配置。设备规格里的 ABI 必须对应安装的原生代码。缺失库、ABI 错误、依赖未解析或加载失败，都可能在模型推理开始前表现为原生链接异常。 测试至少覆盖这些边界：bundle 内容、生成的 APK set、实际安装 split 清单、原生库加载、运行时初始化、模型加载和代表性任务。记录每个阶段是否成功以及首次失败位置。安装成功不证明可选原生库已打包；APK 中存在库也不证明运行时可以加载。相反，若引擎已初始化而任务失败，也不能在没有证据时归因于 split 选择。 用 bundletool 的设备定向功能测试计划交付的 bundle 行为，并把设备规格 JSON 与运行结果一起保存。测试第二种 ABI 或外形时另建记录行，不能复用第一台设备的安装结论。按应用需要覆盖干净安装或更新路径，并使用完整 APK set 安装；仅旁加载 base APK 不能代表完整 split 安装。bundletool 可为连接设备选择必需集合，也支持依据设备规格生成 APK set。 诊断结果应列明准确 ABI 和 split 清单、运行时与应用版本、所需库是否找到并加载、模型加载结果和任务结果。不能从本地单设备 APK set 推导所有 ABI 支持或 Google Play 实际交付结论。这是打包与运行时边界测试；每个声明的配置都需要准确证据。模型性能和兼容性描述，也要与“原生 split 已存在”这个事实区分开。 构建系统中声明了 ABI，并不等于每种 ABI 都在当前 bundle 中启用。要核对打包设置、依赖是否针对相应架构发布、AAB 拆分是否包含它，以及设备实际安装后文件是否可见。若错误出现在 java.lang.UnsatisfiedLinkError，仔细保留异常详情并区分库找不到、符号缺失或依赖加载失败；若原生库成功载入但 Engine 初始化报错，则再检查模型路径和引擎配置。不同错误阶段对应不同责任人和修复方式。 最终验收应把“split 在包里”“split 已安装”“库可加载”“引擎初始化”和“任务成功”作为五个独立观察。自动化报告应附带 bundle hash、APK set manifest、目标设备规格、ABI、异常类型和测试夹具 ID。公开结论只能覆盖所测构建和配置。若安装测试来自本地 bundletool，不应声称已经验证线上 Play 商店交付；两者环境不同，需要分别测试。
调试通用 APK 可运行，但 Bundle 安装时原生初始化失败
开发者在 universal debug APK 上看到本地任务成功。将接近发布的 AAB 转换到另一台设备后，运行时在模型初始化前报原生库加载错误。团队尚未检查目标 APK set。
决策
用 bundletool 为准确设备规格生成并安装 APK set，再检查 ABI split 与原生加载，最后才单独验证模型任务。
预期结果
报告能指出失败在 bundle 定向、包内容、原生加载、引擎初始化还是后续任务。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- COVE-LIFECYCLE-01：Cove 有明确模型加载状态；原生库加载和模型加载是不同阶段。
- BENCHMARK-01：运行结果需记录准确设备、系统、制品、运行时和失败阶段。
收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。
实施流程
- 盘点预期原生库与 ABI. 记录 bundle 构建变体、应用版本、支持 ABI 声明、运行时依赖和文档要求的可选原生库。不要从调试 APK 或源码依赖列表推断发布内容。
- 针对目标设备生成 APK set. 使用 bundletool 和已连接设备，或保存的设备规格 JSON。保存规格与工具/构建版本。ABI、密度、SDK 或安装集不同都应视为独立测试配置。
- 检查生成和安装的 split. 列出 APK set 归档中的 APK，核对目标设备所需原生库是否在配置 split 或 base 内容中。用 bundletool 安装完整集合，再检查安装包中是否存在目标 ABI 路径与库名。
- 在推理前跟踪原生加载. 分别记录原生运行时加载时的链接错误、ABI 不匹配、依赖缺失或初始化成功。只有此边界通过后，才继续模型制品加载和固定任务。
- 重复安装生命周期并限定结论. 按需要测试完整 split 集的干净安装或更新，再跑一个不含隐私的代表性任务。报告准确设备/ABI 和各阶段；不能从一个本地安装外推 Play 交付。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每轮测试保存设备规格和生成 APK set 的身份。
- 安装完整目标 split 集，并在模型任务主张前核对目标 ABI 原生库。
- 原生链接、运行时初始化、模型加载和任务执行分别记录。
- 不从调试包或单设备 bundletool 测试推导普遍 ABI 或商店交付结论。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 通用调试 APK | 方便的本地宽配置安装包 | 库集合可能不同，不能替代目标设备的发布 bundle split。 |
| AAB 归档检查 | 检查 bundle 模块与声明内容 | 能看到输入文件，不单独证明设备装入了哪组 APK split。 |
| 设备定向 APK set | 依据准确设备规格生成并用 bundletool 安装 | 为该 ABI/配置提供最佳本地证据，但仍仅限被测设备和构建。 |
需要避免的失败模式
- 检查 AAB 或源码目录后就认定目标设备安装了所需 .so。
- 用一个设备的 universal/debug APK 推断所有 ABI 和商店交付配置。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
能在 Android 设备上直接安装 AAB 吗？
不能。App Bundle 是发布格式，需先转换成可安装 APK；bundletool 或分发服务会按设备配置生成 APK 集合。安装测试应使用完整集合，不能只装 base APK，还要包含其依赖 split。
通用调试 APK 是否证明每个发布 split 都含运行时库？
不证明。调试包可能包含不同库集合。要为需要验证的设备配置生成并检查接近发布的 APK set，并核对安装后的 ABI 库及目标设备规格。
APK 中存在运行时库是否保证原生初始化成功？
不保证。ABI、传递依赖、加载权限和运行时配置仍可能出错。运行模型任务前要单独验证库加载和引擎初始化，并保留具体异常。