IFW 只拦启动意图 组件实际状态仍然是 enabled 应用察觉不到
为什么 IFW 不会被应用反制
这是 IFW 和 PM 最核心的区别，也是 IFW 解决 PM "复活问题"的根本原因。
PM 模式的问题链
- Bloker 用 PM 把组件状态改成 disabled
- 应用查询组件状态 → 拿到 disabled → 发现被禁了
- 应用捕获异常 → 自动把组件状态改回 enabled
- Bloker 下次看 → 开关被拨回去了
应用从"组件状态"里读到了"自己被禁了"的事实，所以它能反击。
IFW 模式的流程
- Bloker 用 IFW 写规则，不修改组件状态
- 组件状态仍然是 enabled（Bloker 界面上显示的状态可能和 PM 模式不同，这是正常的）
- 应用查询组件状态 → 拿到 enabled → 以为组件还在正常运行
- 应用尝试启动这个组件 → intent 被 IFW 拦下来 → 启动静默失败，没有异常
- 应用完全不知道发生了什么，不会有任何恢复动作
应用从头到尾都没察觉到自己的组件被拦了——它以为组件是好的，只是启动动作好像没发生而已。所以自然不会去"修复"它。
技术层面的解释
| 事件 | PM 模式 | IFW 模式 |
|---|---|---|
| 组件状态查询 | 返回 disabled | 返回 enabled |
| 启动时 | 系统检测到 disabled → 抛异常 | 系统尝试启动 → intent 被拦截 → 静默失败 |
| 应用感知 | 能感知（拿到异常） | 完全无感知 |
| 应用自恢复 | 可以 | 没有机会 |
怎么验证 IFW 真的生效了
关掉一个组件后，不要只看 Bloker 里的开关状态（IFW 下可能显示和 PM 不同）。正确的验证方式：
- 重启应用（或者杀掉再打开）
- 跑到那个功能点去——比如关了广告 service，就打开应用到处点看有没有广告
- 看 Bloker 里的开关状态——如果第二天还关着，说明 IFW 起作用了（PM 的话大概率已经被复活了）
IFW 的"状态显示问题"
切换到 IFW 模式后，Bloker 里有些组件的显示状态（enabled/disabled）可能和你预期不一样——这是正常的，因为 IFW 不修改组件状态。Bloker 界面上的"禁用"标记是 Bloker 自己维护的规则标记，不是 Android 系统层面的组件状态。不要因为看到组件显示 enabled 就以为规则没生效——去实际打开应用看功能有没有被拦才是硬道理。