直接回答
Android 离线语音翻译不是一个单独的“翻译 API”，而是一条由多个阶段组成的处理链。应用首先要取得麦克风权限并采集音频，再按明确的格式把录音交给本地可用的推理路径；随后校验模型输出并向用户展示结果。可选的文字转语音播放又是另一项独立能力。阶段边界很重要：成功录音不代表识别正确，模型返回译文不代表播放可用，模型已经下载也不代表所有辅助服务都不需要网络。Cove Travel 当前代码采用按住录音、结束后再推理的流程：录音完成时返回音频数据，ViewModel 把数据和翻译指令交给本地推理引擎，解析出的译文写入历史记录。项目还单独封装了 Android TextToSpeech 来朗读译文。因此，它是“录音完成后推理”，并不能据此称为连续流式翻译，也不能推断所有设备都有可离线使用的目标语言语音。
场景：旅行者在没有网络时询问路线
旅行者说出一句简短请求，等待屏幕显示译文，也可能点按按钮让手机朗读。模型文件已在出发前安装。可靠的架构必须能区分权限被拒、录音为空或不可用、模型未就绪、推理失败，以及设备上没有目标语言语音等不同问题。
决策
把采集、推理、结果解析、历史记录和语音播放分别封装。界面明确指出哪一阶段失败；即使可选的 TTS 不支持目标语言，文本译文仍应可以查看和使用。
预期结果
用户可以知道应用是否录到声音、生成译文、保存结果或播放语音。模型准备完成后，再通过飞行模式下的端到端测试确认该设备上哪些步骤确实能本地完成。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- 需要权限保护的麦克风采集与生命周期
- 录音格式与模型输入契约
- 译文输出、可选 TTS 与离线失败路径
任务质量需要有版本记录的语料和验收规则；流畅的单条样例不等于准确度结果。
实施流程
- 在用户进入语音功能时申请麦克风权限. 在用户启动语音功能时解释录音用途并申请权限；获得授权前不要读取麦克风。用户拒绝授权时，应展示可恢复的权限状态，而不是把问题伪装成模型或翻译错误。Android 还允许用户通过系统级隐私开关关闭麦克风，因此采集阶段必须能及时停止并反馈原因。
- 定义录音器到模型的输入契约. 明确录音器一次返回完整片段还是连续帧、采用什么音频编码与声道策略、谁负责缓冲，以及停止、打断、取消和输入长度上限如何处理。将明确的音频表示传给推理适配层；不要把平台录音器对象直接当成模型输入，也不要假设任意 PCM 字节都符合模型所需格式。
- 把本地推理作为独立阶段处理. 开始翻译前检查所需模型文件是否存在，以及推理运行时是否就绪。模型资源的所有权应放在界面之外；若原生引擎要求串行访问，也要明确定义并验证。构造包含源语言、目标语言和任务要求的指令，按运行时契约收集完整响应，再解析为有类型的结果，而不是把原始模型文本当成稳定接口。
- 区分文字译文和语音合成. 先把译文作为文字呈现，再将朗读作为用户可选择的后续操作，并检查 Android TTS 是否初始化以及是否支持目标语言。模型在设备上运行，并不证明语音包已经安装，也不证明语音合成无需网络。若无法朗读，应保留文字并指出失败仅发生在语音输出阶段。
- 测试完整流程及其所有中断情况. 模型准备完成后关闭网络，从麦克风授权一直执行到用户看到译文。还要覆盖权限撤销、系统麦克风隐私开关、录音中断、空音频、模型加载错误、格式异常的模型输出、TTS 语言不可用和应用重建。分别保留每个阶段的结果，避免一次成功输出掩盖前面的回退或链路未完成。
- 只陈述实际验证过的行为. 说明产品是按住说话还是连续采集，是显示文字还是播放语音，以及哪些阶段已在断网环境下测试、用户断网前需要完成什么准备。单次成功录音不能证明“实时”“所有设备都可用”或完整的语种覆盖。设备兼容和性能结论需要绑定具体应用版本、模型文件、运行时、设备和任务的原始记录。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 麦克风权限在需要时申请；拒绝授权和系统级禁用均有明确、可恢复的反馈。
- 录音格式、资源所有权、停止与中断行为以及模型输入契约有文档和测试。
- 模型就绪、推理、解析、持久化和可选 TTS 分别报告结果。
- 在记录的设备上完成模型准备后，可于飞行模式跑通完整任务；未支持的阶段会明确披露。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 音频采集 | 通过 Android AudioRecord 等明确的录音 API，并做好权限处理 | 只能说明尝试采集输入；推理前仍需验证录音器状态和实际数据。 |
| 端侧推理 | 已安装的模型与本地运行时接收符合契约的音频表示 | 分别测试模型就绪、输入格式、取消、结果解析及断网执行。 |
| 结果呈现 | 译文文字独立于可选的 TTS 语音播放 | 即使设备没有兼容的语音包，文字译文仍可使用。 |
| 离线声明 | 记录模型准备状态、关闭网络并端到端执行用户任务 | 单有本地推理步骤不能证明模型准备、遥测或语音输出完全不依赖网络。 |
需要避免的失败模式
- 把录完再推理说成连续流式翻译
- 把 TTS 播放等同于模型推理输出
- 认为模型下载完成就证明全链路离线
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- 端侧 AI 架构概览
- Cove Travel 语音翻译实现
- Cove Voice 转写流程
- Android AudioRecord API 参考
- Android 麦克风权限说明指南
- Google AI Edge LiteRT-LM 仓库与运行时文档
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
离线语音翻译等同于离线语音识别吗？
不等同。语音识别负责理解源语言中的语音词句，翻译负责把含义转换为目标语言。应用可以把两者放进同一个模型，但仍应分别测试音频采集、语言方向、译文输出及之后的语音合成阶段，才能知道错误发生在哪里。
Android TextToSpeech 是否一定能离线工作？
不能这样假设。Android 提供 TextToSpeech 服务，但可用引擎和语种语音数据取决于设备配置。应在目标设备上检查初始化和语种可用性，并在准备完成后断网测试；若语音不可用，应保留译文文字，而不是让用户误以为翻译本身失败。
如果应用录完音再推理，可以称为实时翻译吗？
录音结束后才开始推理的流程应称为按轮次或按住说话，而不是连续流式处理。“实时”需要明确的耗时边界，以及中间结果修订、中断、持续运行等证据。界面文案或一条短录音成功，并不足以证明实时能力。
声明离线翻译的最低验证是什么？
先安装并核验所需模型，再关闭网络，实际完成从音频采集到用户依赖结果的完整任务。测试权限处理、失败恢复以及 TTS 等可选输出；凡是仍需要网络的步骤都应记录，不能仅凭推理引擎在本地运行就推断全链路离线。