直接回答
LiteRT-LM Android 接入应当是一条分阶段验证链：先选择运行时支持的模型文件，再添加并解析 Android 库，确认模型路径可读，在后台线程初始化引擎，完成一个代表性请求，最后由明确的所有者关闭原生资源。Google 的 Kotlin 入门文档列出了 Android 依赖坐标、EngineConfig、初始化、创建对话以及显式关闭的基本路径。这是运行时集成参考，不代表每个模型文件、手机、加速器或产品功能都已可用。发布构建应记录解析后的依赖版本，不要只保留一个会移动的版本标签。模型文件和运行时依赖是两个独立输入；任意一方变化都可能改变结果，因此在测试记录中应把它们放在一起。 首次接入先保持范围狭窄：一个文件、一个运行时版本、一个后端请求、一种任务。只有模型格式和所选包支持时，才可把 CPU 路径当作诊断基线；不能因此发布速度比较。初始化和推理应离开主线程，同时呈现加载、失败和取消状态。Gradle 同步成功只证明依赖解析；APK 构建成功只证明代码可以编译打包；两者都不能证明原生库能在设备上加载、模型能打开、对话能完成或用户任务通过验收。因此，最小的有用接入测试应固定模型文件，干净安装应用，初始化引擎，运行一个固定提示样例，保存完整输出，执行取消或关闭，再在释放后重新运行一次。 应用应为引擎指定一个明确的所有者，而不是在 Composable 或每次屏幕重组时创建实例。Repository 或进程级协调器可以串行化原生访问，ViewModel 管理任务状态，界面只观察状态。状态边界应区分文件缺失、正在初始化、就绪、推理中、失败、已取消和已关闭。若 API 会阻塞或产生流式结果，要用生命周期感知的协程连接 UI，避免屏幕的订阅者拥有引擎寿命。请保留准确失败阶段：文件不存在、格式不支持、原生加载失败和模型返回空输出是不同的问题。 不能根据手机名称、依赖声明或配置开关推断 GPU 或 NPU 已可用。后端可能需要额外原生库、运行时支持和具体模型的兼容性；发出后端请求并不表示运行时已经证明确实在那里执行。对 Cove 而言，仓库内的模型元数据描述的是开发用固定制品，并不能证明 APK 已公开发布或广泛设备支持。
首次 Android 接入需要可信的冒烟测试
团队已经把 LiteRT-LM Android 依赖加入新模块，并拿到一个候选模型文件。Gradle 同步成功，但团队还没有在目标环境中验证文件格式、原生初始化、对话输出、取消或关闭路径。
决策
把集成限制为一个有文档依据的模型文件和一条运行时路径，并将构建、原生加载、推理和产品验收分成不同检查。
预期结果
审核者能看到每个阶段准确通过到哪里、剩余哪些未验证，而不会把源码状态扩写成公开设备支持承诺。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- 依赖与解析后的版本
- 模型来源、格式与路径
- 初始化、任务和关闭记录
只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。
实施流程
- 固定集成输入. 记录依赖坐标和解析版本、模型文件的仓库修订、声明格式、构建变体、目标 SDK 和运行时配置，并把官方文档链接放在对应坐标旁。如果参考文档介绍的是另一种推理 API，先解决差异再复制代码。
- 把构建与原生运行检查拆开. 先编译并安装应用，再分别记录文件是否存在、路径是否可读、初始化是否成功、对话是否创建。标出最先失败的阶段。不要把 APK 构建成功标成模型兼容或端侧推理成功。
- 运行固定的代表性任务. 使用简短且不含敏感数据的提示样例，并预先写明输出需要满足什么属性。通过应用自有 Repository 或协调器运行，保存完整响应并检查输出边界。记录运行时只是收到后端请求，还是确实报告了实际后端。
- 释放后重建并复测. 在 API 支持时取消正在运行的请求，通过文档规定的所有者关闭对话和引擎，重建屏幕或任务所有者，再运行同一测试。检查重组或 Activity 重建是否制造重复引擎或遗留旧输出订阅。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 测试记录包含模型、解析后的运行时依赖版本、构建变体和初始化阶段，但不发布没有依据的设备兼容结论。
- 代表任务成功完成或产生可分类失败；取消后出现明确状态，不会悄悄继续运行。
- 对话与引擎的关闭路径均被执行，之后的第二次运行成功或得到清楚分类。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| Gradle 同步或 APK 构建 | 依赖和打包检查 | 仅确认编译期集成，并未打开原生运行时或模型文件。 |
| 引擎初始化 | 原生运行时冒烟检查 | 只确认记录配置下的启动，不等于完整用户任务已经验证。 |
| 代表性端到端样例 | 产品路径验收检查 | 覆盖指定任务和输出规则，但结论仅适用于记录的环境与样例。 |
需要避免的失败模式
- 在主线程加载模型
- 把 APK 构建成功说成设备兼容
- 把后端配置值当成实际执行证据
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- LiteRT-LM repository
- Gemma run guide
- Google AI Edge LiteRT-LM Kotlin API 入门
- Google AI for Developers Gemma 运行指南
- Android Developers 进程和线程
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
加上 LiteRT-LM 依赖是否代表模型受支持？
不代表。依赖提供的是库 API；还要核对模型格式、运行时版本、后端、Android 打包方式和具体模型支持。应保留准确组合的测试记录，不要从编译结果概括兼容性。
引擎初始化应该放在主线程吗？
官方 Kotlin 入门文档指出初始化可能耗时，并建议放在后台线程或协程。加载期间要让 UI 状态保持可观察，也不要让 Composable 拥有可能随重建而被重复创建的原生引擎。
配置 GPU 或 NPU 后能否宣称使用了加速？
不能只根据配置宣称。选择后端的请求不等于运行时证据。记录运行时实际提供的确认信息，并针对确切模型和设备测试；否则只能写“已请求”或“未验证”。