用 Android Test Orchestrator 隔离本地 AI 插桩测试

直接回答

AndroidX Test Orchestrator 是插桩测试 harness 选项，不是通用设备重置服务。官方模型是每项测试在独立的 Instrumentation 实例中运行。启用 clearPackageData 后，它会在测试之间通过运行 pm clear 清除目标应用包数据。这有助于发现测试对持久偏好、数据库或应用文件的意外依赖，也能减少一次测试崩溃污染后续调用的机会。但这不承诺清空 Android 系统缓存、其他应用、内核状态、硬件状态、热历史或所有设备差异。应把边界称为应用包隔离，而不是恢复出厂状态的设备。 是否使用它取决于测试要证明什么。若测试有意验证跨步骤状态，或反复启动应用会遮蔽待测行为，普通插桩执行可能更合适。若独立用例不能继承应用拥有的状态，或单个用例崩溃后仍应启动后续用例，可考虑 Orchestrator。如果应用把模型文件放在应用包拥有的存储中，清除包数据也可能删除大型模型夹具。Runner 不会自动让夹具重新出现；测试设计和时长预算都要包含准备与传输成本。 先固定 Android Gradle Plugin 和 AndroidX Test 依赖，再配置选项。AndroidX runner 指南的 setup 示例使用 ANDROIDX_TEST_ORCHESTRATOR 标签；AGP 8.7 TestOptions.execution API 则记录 ANDROID_TEST_ORCHESTRATOR，并说明 HOST 会关闭设备端编排。不要把一页复制的 token 与另一页的依赖坐标拼成适用于所有版本的配置。应核对准确解析到的 AGP DSL 及其匹配的 AndroidX runner/orchestrator 依赖组合，再检查依赖图和 CI 真正启动的任务。通过项目版本目录使用兼容且明确的坐标，不复制历史示例版本，也不使用动态 latest。 把数据清理当成有后果的边界，而非夹具替代品。可靠的本地推理测试应明确创建或准备模型制品，验证身份与可读字节，然后执行待测行为。如果每个用例都重新安装模型成本太高，可把测试分组：小型状态隔离用例启用包清理，大型模型集成用例则显式管理准备和清理。也可以使用专用测试目录或 setup 阶段，但不能悄悄复用旧生产状态后再称为隔离测试。记录模型是预先暂存、由 harness setup 恢复、下载得到，还是不存在。 不要因为应用包被清理，就假设设备级状态干净。Android 可能保留系统管理的编译产物或其他缓存，Orchestrator 文档没有对这些层作通用清除保证。硬件、系统调度、热状态、外部存储、文档 provider、网络以及其他已安装包，都是不同的环境输入。若结果依赖它们，应通过适当夹具或测试环境声明并控制。无法控制时，把它记录为限制，不要把差异归因于应用数据隔离。 用工程师实际会运行的套件测量成本。尽可能在同一设备或模拟器镜像、测试选择、构建和夹具策略下比较普通执行与 Orchestrator。总耗时应包含启动、包清理、模型夹具准备、重试与失败，而不能只计测试方法。隔离后的套件更慢仍可能是正确性所需；快速但有状态的套件也可用于日常开发。正确性覆盖和吞吐量是两个决策，不应为达到时长目标而削弱重置边界。 本文通用流程不对 Cove 配置或测量行为作任何断言。应用团队采用前应检查实际 AGP 版本、runner 设置、依赖解析、模型存储路径和 CI 设备。模拟器通过只证明该 harness、应用包、制品和环境的组合，不证明所有设备会清理相同状态，也不证明生产模型可免费恢复。测试名称和报告要持续区分应用数据、模型字节与环境状态。

独立测试不断继承前一项的模型选择

一个插桩测试套件验证本地助手；所选模型偏好和已下载制品保存在应用中。某项测试依赖前一项留下的状态才通过，另一项偶尔崩溃并令后续用例不可靠。

决策

对要求独立应用包状态的测试启用 Orchestrator；需要模型时显式准备制品，并为昂贵的模型 setup 保留独立集成路径。

预期结果

套件能够区分状态隔离失败与模型准备失败，并报告 harness 和制品准备的额外耗时，而不会把模拟器称为完全干净。

需要收集的证据

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

• AndroidX Test Orchestrator 文档说明每项测试通过独立 Instrumentation 调用运行，并可用 clearPackageData 在测试间执行 pm clear。
• AndroidX runner 指南示例与 AGP 8.7 TestOptions.execution API 使用不同配置标签；项目须核实准确插件 DSL、匹配依赖及 CI 执行模式。

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

实施流程

1. 固定 runner 工具链. 记录 AGP、AndroidX Test runner 与 orchestrator 版本、解析后的依赖图、设备镜像和 CI task。配置该 AGP 版本支持的执行枚举，并确认 CI 实际启动了 Orchestrator。
2. 明确状态边界. 分别列出应用偏好、数据库、包内文件、模型制品、外部文档、系统管理缓存和设备条件。说明哪些期望被清理，哪些不在应用包数据保证范围内。
3. 按夹具成本分类测试. 区分小型应用状态测试和模型文件较大的集成测试。逐项决定需要包数据清理、显式暂存制品，还是有意跨步骤保留状态。
4. 准备并验证模型输入. 任何包清理之后，都通过有文档记录的测试 setup 安装所需夹具。断言推理前检查制品身份、可读内容及就绪状态，不能依赖前一个用例。
5. 比较套件行为与成本. 在适当情况下用匹配的测试选择对比启用与不启用编排。将调用启动、清理、夹具准备、重试、失败和收尾纳入总时长，并把正确性结果单独保留。
6. 只报告实际测试的边界. 在报告中注明包清理、runner 模式、制品准备、设备镜像和未控制条件。避免声称已清除系统缓存、硬件状态或所有设备差异。

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

验收标准

• CI 报告标明解析到的 AGP 与 AndroidX Test 版本，并确认实际运行的插桩执行模式。
• 需要模型字节的测试在包清理后重新准备并验证制品，不继承其他用例留下的文件或 ready 标记。
• 隔离声明仅覆盖目标应用包；系统缓存、其他应用、硬件及设备条件需另行说明。

决策对照表

需要避免的失败模式

• 应用包数据清理不等于清除系统缓存、其他应用、内核、硬件或热状态。
• 若模型制品存放在应用包数据中，清理可能移除它；不可假设它会自动恢复或无需重建。
• 本文是通用 harness 设计，不证明 Cove 当前已启用 Orchestrator 或某台设备的测量结果。

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

最小复现记录

发布检查表

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

来源与相关证据

• Cove 基准测试方法
• Android Developers：AndroidJUnitRunner 与 Test Orchestrator
• Android Gradle Plugin 8.7 API：TestOptions.execution

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

常见问题