模块兼容性：哪些能用哪些不行

先说结论

能用的：作用域是某个具体应用的、不依赖系统级 Provider/组件的、未加反内置检测的模块。

不能用的：作用域是系统框架的、依赖 LSPosed 系统级 Provider 的、被开发者加了反内置检测的模块。

标准：

这类模块在 LSPatch 下本地模式和便携模式都能用，无需特殊处理。示例：

两种情况：

情况 A：模块代码里检测内置模式后拒绝运行

部分模块开发者因为版权、防倒卖等原因在模块里加了逻辑：检测到自己被嵌入宿主 APK（而不是通过 LSPosed 动态加载）时直接不初始化。这种模块便携模式下无效，但本地模式下因为是 Manager 动态加载的，检测逻辑触发不了，通常能用。

情况 B：模块依赖 LSPosed Provider

某些模块用了 XSharedPreferences 的 Provider 模式——模块从 LSPosed 系统组件里读配置。LSPatch 补丁式框架里没有这个 Provider，所以直接读写会失败。

但很多这类模块同时支持文件存储模式（把配置写到模块自己的 SharedPreferences 或文件里），LSPatch 下通常会自动走降级路径。如果模块不支持降级，那无论本地还是便携模式都用不了。

作用域是系统框架的模块：

这些系统组件没法通过 APK 修补来注入 LSPatch 运行时。想玩这类模块必须回到 LSPosed + Zygisk/Riru 路线（需要 Root）。

依赖 Zygote 注入时机的模块：

这类模块在 LSPatch 下可能 hook 不到目标方法。

三步：

1. 看模块描述或仓库 README

正规模块会明确标注兼容性：

2. 搜社区反馈

酷安、GitHub Issues 搜模块名 + "LSPatch" 或 "免 Root"，看有没有人成功过或报过不兼容。

3. 实际试

最坏情况就是修补完发现模块不生效，卸载重装即可。风险可控。

LSPatch 原版停更于 2023 年底，opatch/onpatch 持续更新。模块的核心 API（de.robv.android.xposed.*）基本稳定，但某些新版本 API（比如 Hook 高级特性）可能依赖新版 LSPosed 核心。

如果模块需要 "LSPosed core ≥ v1.9.x" 之类的条件：

如果模块需要 "API 101" 或更高版本：LSPatch 原版 v0.6 已经支持，没问题。