ColorOS 重启后无障碍服务失效？把它拆成三层讲清楚

ColorOS 上依赖无障碍的 App 重启一次掉一次，同功能的 App 却有的掉有的不掉。原因分三层：secure 设置本身、定制 ROM 的自启动与省电 force-stop，以及 ColorOS 安全管控按包名主动关闭无障碍。附 adb 判断方法。

关键词：ColorOS、OPPO、一加、真我、无障碍服务、自启动、保活

现象

在 ColorOS（OPPO / 一加 / 真我）上，自动化、跳广告这类依赖无障碍服务的第三方 App，经常是重启一次就掉一次，得手动去设置里重新开启。

更让人困惑的是：同样功能的 App，有的掉，有的不掉。 于是很多人第一反应是"系统 bug"或者"这个 App 写得太烂"。其实都不是——原因至少分三层，而且都不在 App 这一侧。

第一层：无障碍启停只认一个 secure 设置

无障碍服务是否启用，完全由 Settings.Secure.enabled_accessibility_services 这一个值决定，它是 : 分隔的 包名/服务类名 列表。

原生 Android 的行为是：

• 只要组件名还在这个列表里，开机、以及服务进程崩溃之后，系统都会自动重新 bind 拉起，开发者不需要自己写"重启后重新开无障碍"的逻辑。
• 只有 force-stop 才会把它关掉，而且 force-stop 时系统会顺手把条目从列表里删掉。

换句话说，"启停"这件事本身是系统管的，正常情况不会掉。

第二层：定制 ROM 加的限制

定制 ROM（包括 ColorOS）通常在原生之上再加两道：

1. 阻止应用自启动。 无障碍服务被系统拉起，本质上也算"自启"，一旦被自启动策略拦住，系统就不会再拉它。
2. 省电策略 force-stop。 应用被省电策略强停时，等同于 force-stop，无障碍条目会被一并移除。

所以"重启失效"很多时候不是 bug，而是这两条之一。

判断方法很简单——重启后看一眼条目在不在：

adb shell settings get secure enabled_accessibility_services

• 条目没了 → 被删了（大概率是省电策略 force-stop）。
• 条目还在、但服务没跑 → 自启动被拦，系统没把它拉起来。

第三层：ColorOS 的安全管控会"主动"关无障碍

这一层最容易被忽略，也是最反直觉的。

ColorOS 的安全检测 / 安全中心会按包名对"带无障碍的应用"做风险管控。一旦命中，它会直接调用内部接口把该应用的无障碍关掉（AccessibilityUtils.setAccessibilityServiceState(..., false)），必要时还会连进程一起清掉。

而"哪些包会被跳过"是由 OPPO 云端下发的名单决定的（通过 com.oplus.romupdate 这个 provider 的 update_list 表下发到本机）。

这就完美解释了开头那个诡异现象：

• 名单里的包：系统该拉起就拉起，不受影响；
• 不在名单的包（包括同功能、只是换了包名的分支/魔改版）：被判定命中，无障碍被主动关掉。

小结

ColorOS 上"重启后无障碍失效"，原因基本是下面三条之一：

1. 被 ROM 的自启动策略拦住，服务没被拉起；
2. 被省电策略 force-stop，无障碍条目被顺带删除；
3. 被 ColorOS 的安全管控主动关闭。

区分办法：先跑一次 settings get secure enabled_accessibility_services——

• 条目消失 → 大概率是 1 / 2；
• 条目在但服务没起 → 是 1；
• 条目被删且系统日志里能看到安全模块动作 → 是 3。

相关阅读：ColorOS 老是弹「检测到“XX”获取无障碍权限」是怎么回事？

本文基于某个版本的 ColorOS 真机数据与系统 APK 反编译分析，具体行为会随系统版本、云端名单更新而变化。