同一台手机上有 App 的开屏广告能被跳过、有的完全没反应，这个对照本身就有信息量：在同一次会话、时间接近的前提下，能跳过的那个 App 说明无障碍链路当时是通的，服务大概率还在启用列表里。所以先不要动规则文件，也不要急着重装，先用现象把「规则没覆盖」和「服务被回收」两条支路分开，再决定改哪一处。真正容易判断错的是另一种情况：所有 App 全部失效，或者上一次有效是几小时前，这时服务的嫌疑就要往前排。

开屏广告拦不住，先用现象分流：手动点得到跳过按钮但没被自动点，优先查规则是否覆盖了这个包名；连手动点都找不到按钮、或者多个 App 同时全失效，优先查无障碍服务是否还在启用列表。规则核对靠包名检索，服务核对靠 adb 读 enabled_accessibility_services。改动时一次只动一个变量，改完 force-stop 冷启动复现一次再记录。判断边界是：服务出现在启用列表里只说明授权还在，不代表进程存活，需要结合复现结果确认。

先看广告形态：有跳过按钮没被点，还是广告原样展示

打开目标 App，先不要管清理工具，手动看一遍开屏：广告停留的几秒里，屏幕角落或底部有没有可点的跳过、关闭、X 之类控件。这个动作决定后面查哪条支路。

• 能手动点到跳过按钮，但工具没替你点：服务通常还活着，问题更可能出在规则侧——包名没被规则覆盖、控件匹配条件对不上（文案、resource-id、坐标随版本变动）、或者动作触发得太早，开屏还没渲染完就执行了。
• 广告原样展示，整屏没有任何可跳过控件，或者连工具的任何反馈都没有：先怀疑服务侧——无障碍服务被系统回收、被电池策略冻结、被其他 App 抢占，或者根本没授权成功。
• 多个 App 同时失效、之前能用：即使单个 App 有跳过按钮，也建议先查服务，因为全局失效更像链路断了而不是规则集体失效。

记录方式尽量具体：记下 App 名称与包名、开屏广告停留的秒数、跳过控件的位置和文案、当时是否手动点成功、以及复现的时间点。这几项是后面两节做对照的依据，尤其是「同一时段内哪个 App 有效」这条，比其他描述都更有用。

在规则文本里搜目标应用的包名

确认规则覆盖的第一步是拿到准确的包名，不要凭应用显示名去猜。两种途径都可靠：

• 系统设置 → 应用 → 找到该 App → 应用信息页，部分系统在页面底部或右上角菜单里显示包名；不同 ROM 位置不一样，找不到就走下一条。
• 用 adb 列出全部包名再过滤，这一条最稳：

adb shell pm list packages | grep -i 关键词
# Windows 命令行可用：
adb shell pm list packages | findstr /i 关键词

拿到包名后，在规则文件里检索。规则文件通常是 json、xml 或纯文本列表，先用普通字符串检索一遍：

grep -n -i 'com.example.targetapp' /path/to/rules.json

命中与未命中的判断要留一点余地：命中了不代表规则生效——检查这一条有没有被注释掉、有没有 disabled 之类的开关字段、匹配条件是不是写成了更宽的父级前缀（比如只写了 com.example 而没有具体到应用）。未命中也不一定就是没覆盖，规则可能用了通配符或正则，这时反向验证：把规则里的匹配模式单独拿出来，用 grep -E 去匹配目标包名，看能不能对上。对不上，就是规则确实没覆盖这个 App，先补规则再谈服务。

用 adb 复查无障碍服务是否还在启用列表

这一步排除服务被系统回收的支路。核心是读 secure 设置里的启用列表，而不是只看设置界面里那行开关——有些情况下界面显示开启，列表内容已经被改写。

adb shell settings get secure enabled_accessibility_services
adb shell settings get secure accessibility_enabled

第一条命令的输出是一个用冒号分隔的列表，每项形如 包名/服务类名 或 包名/.类名。只看斜杠前面的包名部分即可。第二条命令返回 1 表示无障碍功能总开关是开的，返回 0 或 null 表示整体关闭。

• 输出里出现了目标包名，且 accessibility_enabled 为 1：服务在启用列表里，授权没丢。此时若第 1 步的现象是「有跳过按钮没被点」，把重心放回规则；若是「完全无反应」，继续确认进程是否存活，列表里有条目不等于服务已绑定。
• 输出里没有目标包名，或列表为空：服务已被移出启用列表，可能是被系统回收、被用户或清理类工具关闭、或重装后授权丢失。这时改规则不会有任何效果。
• 部分系统可以进一步看绑定状态，输出格式随版本差异较大，需要结合环境确认：

adb shell dumpsys accessibility | grep -i -A3 'bound'

做单变量验证：只改规则，或只重启服务

规则和服务同时改，改完有效也说不清是哪一处起的作用，下次出问题还是没法判断。所以拆成两次实验，每次只动一个变量。

1. 第一次只改规则：在规则文件里补上目标包名（或修正匹配条件），不动无障碍开关，不重装应用。保存后先 adb shell am force-stop 目标包名，再手动冷启动，观察开屏是否被处理。
2. 第二次只动服务：把上一步的规则改动还原回去，然后关闭再重新开启该无障碍服务（或在设置里取消授权后重新授权）。同样 force-stop 再冷启动，观察同一次开屏的表现。

两次实验都记录同一组字段：开屏时间点、跳过控件是否出现、工具是否响应、以及复现后的启用列表内容。顺序上建议先做规则，因为改动可回滚、影响面小；如果规则命中后行为毫无变化，再做服务重启，结论会更干净。需要提醒的是，用 adb shell settings put secure enabled_accessibility_services 直接写这个值是覆盖整个列表，写错会把其他无障碍服务一起清掉，动手前先把原值记下来，能不用这条命令就不用。

把分流结论固化成排查顺序

下次再遇到拦不住，按下面四步走，每一步都有一个明确的通过标准，走不通再进入下一步。

1. 现象：手动能不能点到跳过控件；是单个 App 失效还是多个 App 同时失效。单个 App 且能点到 → 进第 2 步；多个同时失效或完全无控件 → 可以直接跳到第 3 步。
2. 规则：用 pm list packages 拿到包名，在规则文件里检索，确认命中且未被禁用、匹配条件没有写偏。通过则进第 4 步；未命中就先补规则，补完仍无效再进第 3 步。
3. 服务：读 enabled_accessibility_services 和 accessibility_enabled。列表里没有目标包名就重新授权，有则检查进程是否被系统冻结、是否被清理类应用关闭。处理后进第 4 步。
4. 复现：force-stop 目标 App 后冷启动，在开屏窗口期内观察，并记录当次现象和当时的启用列表。复现成功才算这一轮排查闭环；仍失败则回到第 1 步，重新确认现象描述是否准确。

这套顺序的价值在于可重复：每次只需要回答「这次卡在哪一步」，而不是从头把所有配置翻一遍。规则文件和无障碍授权都是会随应用更新、系统升级变动的，保留每次的记录比记住某一次的结论更管用。