ContentProvider 作用域机制：比传统方式更稳的读取通道

FPA 的公开特性清单里有一句很技术的话：「使用 ContentProvider 来获取作用域，更为稳定」。这句话值得单独展开，因为「作用域怎么被读到」正是动态加载能否生效的关键一环。

作用域是什么、为什么要读

作用域就是「哪个应用挂哪些模块」的对应表。框架被 patch 进目标应用后，启动时必须读到这张表，才知道要挂载什么。表本身由 FPA 本体管理——你在 FPA 里勾模块（勾选模块让功能生效），改的就是这张表。

ContentProvider 是什么角色

ContentProvider 是安卓提供的一种跨应用数据共享机制：一个应用可以把部分数据以标准接口暴露出去，别的应用按规范查询。FPA 的做法是：

• FPA 本体作为数据的提供方，托管作用域表；
• 被 patch 的应用里，框架代码启动时通过 ContentProvider 标准接口向 FPA 查询自己的模块清单。

整条通道用的是系统官方支持的通信方式，没有特权操作、没有系统层干预。

「更为稳定」稳在哪

对比一下免 Root 方案早期常见的做法就明白了：跨进程读数据如果依赖私有机制或非常规通道，系统更新、厂商后台策略、权限收紧都可能掐断它，表现为「昨天还好好的今天就不生效」。ContentProvider 是系统契约的一部分——只要两个应用都活着、权限就位，通道就在。这也是 FPA 把它列成官方特性的原因。

与 Shizuku 的关系

ContentProvider 通道本身是普通应用间通信，不需要特权；而作用域体系里还有需要更高一点权限的环节（比如读取应用信息），那部分由 Shizuku 补位（用 Shizuku 提供作用域）。两者是配合关系：Shizuku 授权进门，ContentProvider 持续供数。

对排查的启示

理解这条机制，两个经典症状就有了解释：

• FPA 被清理/停用后成品打不开——提供方不在，ContentProvider 查询无门（为什么 FPA 不能卸载）；
• 勾了模块不生效——通道某一端被系统休眠或权限收缩，重开双方应用、确认授权后往往恢复（排查见模块加载失败的常见原因）。

作用域机制之上还有一层增强设计：异步请求捕获。