HarmonyOS 鸿蒙Next中在录制屏幕前已申请后台长时任务,但应用进程还是有概率性在退出后台时被系统杀掉

HarmonyOS 鸿蒙Next中在录制屏幕前已申请后台长时任务,但应用进程还是有概率性在退出后台时被系统杀掉

已申请后台长时任务,类型是audioRecording,但启动录屏后,还是存在概率性应用会被系统杀死,看日志抛出这个,会是什么原因

processName=xxx.xxx.xxxxx, msg=Kill Reason:ILLEGAL_AUDIO_CAPTURER_BY_SUSPEND

6 回复

后台长时任务有数量和运行限制,可以根据以下说明检查一下,如果符合要求,那就提个工单

数量限制:一个UIAbility(FA模型则为ServiceAbility)同一时刻仅支持申请一个长时任务,即在一个长时任务结束后才可能继续申请。如果一个应用同时需要申请多个长时任务,需要创建多个UIAbility;一个应用的一个UIAbility申请长时任务后,整个应用下的所有进程均不会被挂起。

运行限制

  • 申请长时任务后,应用未执行相应的业务,系统会对应用进行管控,即应用退至后台会被挂起。如系统检测到应用申请了AUDIO_PLAYBACK(音视频播放),但实际未播放音乐。
  • 申请长时任务后,应用执行的业务类型与申请的不一致,系统会对应用进行管控,即应用退至后台会被挂起。如系统检测到应用只申请了AUDIO_PLAYBACK(音视频播放),但实际上除了播放音乐(对应AUDIO_PLAYBACK类型),还在进行录制(对应AUDIO_RECORDING类型)。
  • 申请长时任务后,应用的业务已执行完,系统会对应用进行管控,即应用退至后台会被挂起。
  • 若运行长时任务的进程后台负载持续高于所申请类型的典型负载,系统会对应用进行管控,即应用退至后台会被挂起或终止。

说明

  • 应用按需求申请长时任务,当应用无需在后台运行(任务结束)时,要及时主动取消长时任务,否则系统会强行取消。例如用户主动点击音乐暂停播放时,应用需及时取消对应的长时任务;用户再次点击音乐播放时,需重新申请长时任务。
  • 若音频在后台播放时被打断,系统会自行检测和停止长时任务,音频重启播放时,需要再次申请长时任务。
  • 后台播放音频的应用,在停止长时任务的同时,需要暂停或停止音频流,否则应用会被系统强制终止。

更多关于HarmonyOS 鸿蒙Next中在录制屏幕前已申请后台长时任务,但应用进程还是有概率性在退出后台时被系统杀掉的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


感谢大佬回答,我这边核对一下,

基本信息

  • 姓名: 张三
  • 年龄: 28
  • 职位: 软件工程师

技能

  • Python
  • Java
  • C++

项目经验

  • 项目一
    • 描述: 使用Python开发了一个自动化测试工具
    • 技术栈: Python, Selenium
  • 项目二
    • 描述: 开发了一个电商网站
    • 技术栈: Java, Spring Boot, MySQL

联系方式

楼主,当前这个概率性被系统杀死出现的频率是多少?可否提供一下复现Demo?

你好,这个概率大概是1/10,若出现一次可能会存在区域时间内概率提高至1/5,应用较为复杂不好剥离demo,大概就是录屏同时采集内录音频,在反复切换后台前台时,或等待自动熄屏时,容易出现被系统杀死。

鸿蒙Next中后台进程被杀的原因可能包括:

  • 系统资源紧张时触发自动回收机制
  • 长时任务权限未完全适配新版本系统
  • 其他高优先级系统任务占用资源
  • 应用后台行为不符合鸿蒙后台管理策略

典型解决方案:

  • 检查并确保正确使用ContinuousTaskMission接口
  • 适配最新的后台任务管理规范
  • 优化应用后台资源占用
  • 添加必要的后台运行白名单配置

从日志信息来看,应用被系统杀死的原因是"ILLEGAL_AUDIO_CAPTURER_BY_SUSPEND",这表明系统检测到应用在挂起状态下仍尝试进行音频捕获操作,违反了HarmonyOS Next的安全机制。

可能的原因包括:

  1. 应用在进入后台后没有正确处理音频捕获状态,导致系统认为存在违规行为
  2. 后台长时任务申请可能没有完全生效或被系统回收
  3. 录屏功能与音频捕获的权限或生命周期管理存在冲突

建议检查:

  1. 确保在应用进入后台时正确维护音频捕获状态
  2. 验证后台长时任务申请是否完整且符合规范
  3. 检查录屏功能的权限声明和实现方式是否符合HarmonyOS Next的要求,
回到顶部