被 PM 禁了又复活 换 IFW 再禁一次就钉死了
最彻底的方案:IFW
如果你的设备已经 root,且某些应用的组件用 PM 方式关掉后又自动打开了——直接换 IFW,一劳永逸。
典型会复活的组件类型
- 广告 SDK 的 activity:TTAdActivity、GDTAdActivity、KSAdActivity 等,PM 关了,应用一启动广告流程就会把它们重新启用
- 推送 service:JPush 的 PushService、个推的 PushService,PM 关了但 SDK 内部有自恢复逻辑
- 厂商通道的 receiver:华为/小米/OPPO 的推送 receiver,系统层面可能会恢复
- 统计上报 service:友盟 Bugly 的 service,PM 禁了下次 crash 上报时又会开
切换步骤
假设你在 PM 模式下关掉了字节跳动系应用的 TTAdActivity,第二天发现它又开了:
- 打开 Bloker 设置页
- 把控制器从 PackageManager 改成 Intent Firewall
- 回到那个应用的组件详情页
- 找到
TTAdActivity,关掉它的开关 - Bloker 这次会写 IFW 规则,而不是改 PM 状态
- 打开应用跑一圈,确认广告没了
- 第二天再回 Bloker 看——开关应该还是关的
更彻底的组合方案:IFW + PM
如果你的设备已 root,Bloker 还提供了第三种选项——IFW + PM 双控制器组合。这意味着:
- 关掉组件时,Bloker 同时写 PM 规则(改组件状态为 disabled)和 IFW 规则(拦截启动意图)
- PM 层直接禁状态,IFW 层额外拦截
- 应用就算复活了 PM 状态,IFW 层还有一道闸拦着 intent
这是最保险的方案,但对普通应用来说纯粹 IFW 就够了——双保险的优势在于极端场景下也能生效(比如某个组件通过非 intent 方式启动时 PM 层能兜住)。
什么时候 PM 还有价值
虽然 IFW 是更优方案,但 PM 也不是完全没用的:
- PM 方式可以直接从系统层面禁掉组件,哪怕 Bloker 被卸载或 IFW 规则文件丢失,PM 规则还在
- 有些简单应用没有自恢复逻辑,用 PM 也一样稳定
- 如果你不 root,只能走 Shizuku + PM 路线(虽然功能受限)
但只要能用 IFW,就优先 IFW——大厂应用、有自恢复逻辑的应用、你不确定的应用,全部 IFW。