直接回答
锁屏是录音生命周期中的测试节点,不代表录音一定要继续或一定要停止。实际行为取决于产品承诺、录音如何启动、麦克风权限、服务声明、Android 版本与目标 SDK,以及应用自身的音频采集逻辑。麦克风前台服务必须满足相应服务类型和权限规则;Android 还限制从后台启动使用时麦克风服务。工程师应从真实用户操作路径测试锁屏前后,并记录应用实际行为。 首先要区分 Activity 不再可见和录音所有者被停止。Activity 进入暂停或停止状态时,适当拥有录音的服务可能继续运行;如果录音器绑定在 Activity 上,屏幕生命周期变化也可能让它被释放。两种情况都不能只凭一次回调推断。应为权限、就绪、录音中、暂停或中断、收尾、转写、停止绘制状态图。每次状态转移都要更新通知或屏幕,并在任务结束时释放麦克风。 其次要区分采集和转写。录音可以继续而推理等待,也可以先停止采集并保存片段,之后再转写。这是不同产品行为,分别带来内存、隐私和中断边界。如果应用把音频缓存在内存里,锁屏、进程结束或内存压力可能丢失片段;如果写入本地存储,就要保护文件生命周期和删除行为。服务如果只是在处理已录制文件,就不要显示“正在录音”。 逐次只改变一个条件测试:用户在前台开始录音;用户锁屏;屏幕自动熄灭;应用进入后台;权限被撤销;用户点击通知停止;进程被杀后重建;电话或另一款录音应用抢占音频源;任务重新打开。记录时间、状态转移、录音器结果、文件是否存在及其时长、收尾是否完成和推理是否完成。诊断日志不要保存真实会议内容。 若锁屏时产品有意停止录音,应明确告知用户并保留已完成片段。若设计为继续录音,就要在支持的系统配置上验证前台服务和通知,确保停止操作有效。单台设备成功只能证明那台设备和该构建,不代表所有 Android 手机完全相同。本地推理引擎也不会改变麦克风平台规则。 本指南提供测试方法,不代表 Cove Voice 当前公开版本有锁屏录音功能。项目源码本身并不能证明公开应用在屏幕锁定时可以录音。实施时先写清用户承诺、通知和中断处理;再从可见 Activity 开始并记录权限、服务类型和状态;锁屏、解锁并逐项测试权限撤销和音频抢占;先核对音频是否收尾,再将推理作为独立阶段运行;最后测试进程重建。如果任务不能安全恢复,就明确显示已停止,只保留应用确实能够验证的部分。验收标准是已复现、用户可见的行为,不是“锁屏后麦克风自然不会变”的假设。
屏幕熄灭后录音结果变短
用户在前台开始录音笔记并把手机放入口袋。后来转写比预期短。工程师需要判断是锁屏后采集停止、音频收尾失败、另一应用占用麦克风,还是转写只处理了已保存部分。
决策
在采集边界记录阶段状态,并针对声明的系统版本和应用构建重复同一路径,再决定是否改变服务策略。
预期结果
团队能说明录音在锁屏后继续、暂停还是停止,并区分音频缺失与后续转写失败。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来,结论才可复核:
- 锁屏前后的采集状态
- 音频文件与收尾记录
- 单独执行的转写结果
只有记录了模型身份、构建配置、实际后端、任务样例和失败情况,运行时比较才可复核。
实施流程
- 定义锁屏时预期行为. 说明用户主动开始后锁屏是否继续、通知和停止操作是否保留、哪些中断会结束录音、部分音频是否保存。如果产品不承诺持续录音,应在用户开始前展示限制。
- 锁屏前记录权限和服务状态. 从可见界面启动,确认麦克风权限、适用的前台服务类型和通知,再记录带时间戳的状态转换。不能在没有核实的后台状态启动使用时麦克风服务。
- 测试锁屏和中断边界. 逐项锁屏解锁、切换后台、撤销权限、点击通知停止并模拟音频中断。每次只改变一个条件,记录采集状态、收尾结果和输出文件元数据;诊断日志不要写私人语音。
- 先检查音频再启动推理. 转写前确认音频片段存在且完成收尾。把录音时长、文件边界与预期任务对照,再独立测试转写。没有录下来的内容,模型也无法恢复。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作,同时避免记录用户私密内容。
验收标准
- 每种锁屏路径都有明确结局:继续、按设计停止、中断或失败。
- 停止、撤销权限或失败后录音器释放麦克风,保留音频遵守已说明的规则。
- 只有当音频阶段证据支持时,才把转写失败归因为采集失败。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| Activity 拥有录音 | 采集绑定可见屏幕生命周期 | 离开页面时可能停止;必须记录并测试释放行为。 |
| 用户可见持续会话 | 由合规前台服务拥有采集 | 需满足当前权限、服务类型、通知和启动限制。 |
| 先存音频后处理 | 采集与推理分阶段 | 便于后续处理,但增加本地文件保留和删除边界。 |
需要避免的失败模式
- 依据一次回调推断行为
- 把录音状态显示成转写状态
- 将不完整录音归咎于模型
还要避免静默回退、版本未固定、缺少取消处理,以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答,且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
- Android persistent background work
- Android Developers — 前台服务变更
- Android Developers — 请求运行时权限
- Android Developers — 音频采集
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
Android 是否总会在锁屏时停止麦克风录音?
不能对所有应用架构一概而论。应用的资源所有者、服务类型、权限时机、系统版本和目标 SDK 都重要。请测试准确的用户启动路径并记录行为。
转写不完整时要先换模型吗?
先确认源音频是否完整并已收尾。将采集时长和文件边界与预期任务比较,再单独测转写。没有录到的音频不是换模型可以补回来的。
离线录音器能否宣称数据不离开设备?
不能只看模型位置。还需分别检查采集、推理、诊断、同步、备份、导出和分享流程。隐私说明必须与实际数据路径一致。