运行时与集成

Android 锁屏时如何验证录音状态

锁屏是一个生命周期测试节点,不代表录音必然继续或必然停止。

审核状态: 内容已校验;中文稿供用户审核 · 2026-10-03 · Fact IDs: ANDROID-AUDIO-01, ANDROID-BG-01, ANDROID-MICROPHONE-FGS-2026-01

直接回答

锁屏是录音生命周期中的测试节点,不代表录音一定要继续或一定要停止。实际行为取决于产品承诺、录音如何启动、麦克风权限、服务声明、Android 版本与目标 SDK,以及应用自身的音频采集逻辑。麦克风前台服务必须满足相应服务类型和权限规则;Android 还限制从后台启动使用时麦克风服务。工程师应从真实用户操作路径测试锁屏前后,并记录应用实际行为。 首先要区分 Activity 不再可见和录音所有者被停止。Activity 进入暂停或停止状态时,适当拥有录音的服务可能继续运行;如果录音器绑定在 Activity 上,屏幕生命周期变化也可能让它被释放。两种情况都不能只凭一次回调推断。应为权限、就绪、录音中、暂停或中断、收尾、转写、停止绘制状态图。每次状态转移都要更新通知或屏幕,并在任务结束时释放麦克风。 其次要区分采集和转写。录音可以继续而推理等待,也可以先停止采集并保存片段,之后再转写。这是不同产品行为,分别带来内存、隐私和中断边界。如果应用把音频缓存在内存里,锁屏、进程结束或内存压力可能丢失片段;如果写入本地存储,就要保护文件生命周期和删除行为。服务如果只是在处理已录制文件,就不要显示“正在录音”。 逐次只改变一个条件测试:用户在前台开始录音;用户锁屏;屏幕自动熄灭;应用进入后台;权限被撤销;用户点击通知停止;进程被杀后重建;电话或另一款录音应用抢占音频源;任务重新打开。记录时间、状态转移、录音器结果、文件是否存在及其时长、收尾是否完成和推理是否完成。诊断日志不要保存真实会议内容。 若锁屏时产品有意停止录音,应明确告知用户并保留已完成片段。若设计为继续录音,就要在支持的系统配置上验证前台服务和通知,确保停止操作有效。单台设备成功只能证明那台设备和该构建,不代表所有 Android 手机完全相同。本地推理引擎也不会改变麦克风平台规则。 本指南提供测试方法,不代表 Cove Voice 当前公开版本有锁屏录音功能。项目源码本身并不能证明公开应用在屏幕锁定时可以录音。实施时先写清用户承诺、通知和中断处理;再从可见 Activity 开始并记录权限、服务类型和状态;锁屏、解锁并逐项测试权限撤销和音频抢占;先核对音频是否收尾,再将推理作为独立阶段运行;最后测试进程重建。如果任务不能安全恢复,就明确显示已停止,只保留应用确实能够验证的部分。验收标准是已复现、用户可见的行为,不是“锁屏后麦克风自然不会变”的假设。

屏幕熄灭后录音结果变短

用户在前台开始录音笔记并把手机放入口袋。后来转写比预期短。工程师需要判断是锁屏后采集停止、音频收尾失败、另一应用占用麦克风,还是转写只处理了已保存部分。

决策

在采集边界记录阶段状态,并针对声明的系统版本和应用构建重复同一路径,再决定是否改变服务策略。

预期结果

团队能说明录音在锁屏后继续、暂停还是停止,并区分音频缺失与后续转写失败。

需要收集的证据

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

  • 锁屏前后的采集状态
  • 音频文件与收尾记录
  • 单独执行的转写结果

只有记录了模型身份、构建配置、实际后端、任务样例和失败情况,运行时比较才可复核。

实施流程

  1. 定义锁屏时预期行为. 说明用户主动开始后锁屏是否继续、通知和停止操作是否保留、哪些中断会结束录音、部分音频是否保存。如果产品不承诺持续录音,应在用户开始前展示限制。
  2. 锁屏前记录权限和服务状态. 从可见界面启动,确认麦克风权限、适用的前台服务类型和通知,再记录带时间戳的状态转换。不能在没有核实的后台状态启动使用时麦克风服务。
  3. 测试锁屏和中断边界. 逐项锁屏解锁、切换后台、撤销权限、点击通知停止并模拟音频中断。每次只改变一个条件,记录采集状态、收尾结果和输出文件元数据;诊断日志不要写私人语音。
  4. 先检查音频再启动推理. 转写前确认音频片段存在且完成收尾。把录音时长、文件边界与预期任务对照,再独立测试转写。没有录下来的内容,模型也无法恢复。

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

验收标准

  • 每种锁屏路径都有明确结局:继续、按设计停止、中断或失败。
  • 停止、撤销权限或失败后录音器释放麦克风,保留音频遵守已说明的规则。
  • 只有当音频阶段证据支持时,才把转写失败归因为采集失败。

决策对照表

维度选择或证据解读方式
Activity 拥有录音采集绑定可见屏幕生命周期离开页面时可能停止;必须记录并测试释放行为。
用户可见持续会话由合规前台服务拥有采集需满足当前权限、服务类型、通知和启动限制。
先存音频后处理采集与推理分阶段便于后续处理,但增加本地文件保留和删除边界。

需要避免的失败模式

  • 依据一次回调推断行为
  • 把录音状态显示成转写状态
  • 将不完整录音归咎于模型

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

最小复现记录

层级记录内容
设备厂商、型号、芯片、内存档位、操作系统版本
软件应用版本和 Git 提交号
模型系列、变体、版本、格式、文件长度、摘要、量化方式
运行时名称、版本、请求后端及实际后端证据
工作负载样例版本、输入摘要、提示词摘要、输出策略
结果完成、失败、取消、回退及保护隐私的诊断信息

发布检查表

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

来源与相关证据

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

常见问题

Android 是否总会在锁屏时停止麦克风录音?

不能对所有应用架构一概而论。应用的资源所有者、服务类型、权限时机、系统版本和目标 SDK 都重要。请测试准确的用户启动路径并记录行为。

转写不完整时要先换模型吗?

先确认源音频是否完整并已收尾。将采集时长和文件边界与预期任务比较,再单独测转写。没有录到的音频不是换模型可以补回来的。

离线录音器能否宣称数据不离开设备?

不能只看模型位置。还需分别检查采集、推理、诊断、同步、备份、导出和分享流程。隐私说明必须与实际数据路径一致。