系统级 Hook 与 LSPatch 的天然矛盾

核心矛盾：注入时机

Xposed 框架能 hook 到应用启动的最早期阶段，是因为它的注入点在 Zygote——Android 所有应用进程的共同祖先进程。Zygote 在 fork 每个应用之前就完成了 Xposed 的 Hook 环境初始化，所以应用进程从诞生的那一刻起就在 Hook 环境里。

LSPatch 的注入点是 AppComponentFactory——这是应用 Manifest 里声明的组件工厂，由 Android 框架在实例化应用的 Application 类之前调用。时机比 Zygote 晚很多，但足够让 LSPatch 在应用的 Application.onCreate 之前完成运行时初始化。

为什么这对系统级模块是致命的

系统级模块（修改 SystemUI、设置应用、权限管理框架等）需要 hook 的目标不在普通应用里，而在：

• SystemUI：状态栏、通知栏、锁屏——这些是由系统进程 com.android.systemui 启动的，没有独立 APK 可以被修补
• 系统 Framework：android.os、android.view、android.content 等核心类——这些类在 Zygote 里就已经 preload 好了，AppComponentFactory 阶段已经晚了
• 系统 Service：PackageManagerService、ActivityManagerService、WindowManagerService 等——运行在 system_server 进程，根本没有 APK

简单说：系统组件不存在独立 APK → 没法修补 → 没法嵌入 LSPatch 运行时 → 模块根本没有被加载的机会。

能用 LSPatch 实现的上限

LSPatch 能做的事情严格限定在：目标应用进程内部、由目标应用自己加载的方法和类。

这包括：

• 修改应用自己的 UI 布局、加按钮、改文案
• Hook 应用调用的 API（比如网络请求、图片加载）
• 在应用进程里注入自己的逻辑（比如修改返回值、替换实现）

不包括：

• 修改状态栏、导航栏、系统手势
• 拦截权限请求、修改权限行为
• 修改应用的启动流程（<clinit> 等类加载器初始化阶段的 Hook 做不了）
• 修改系统级的组件生命周期

如果你需要系统级模块

唯一的路：Root + Zygisk/Riru + LSPosed。

具体步骤（简述）：

1. 解锁设备 Bootloader
2. 刷入 Magisk / KernelSU / APatch
3. 安装 LSPosed 模块（Magisk 模块形式）
4. LSPosed 在 Zygote 阶段注入，所有应用进程从诞生就带上 Hook 能力

这条路的代价：

• 解锁 BL 会清除数据、丢保修、某些厂商设备永久不支持
• Root 后银行/游戏类应用可能检测到并拒绝运行
• 系统升级后可能需要重新刷模块

务实的选择

在当前生态下：

本站聚焦 LSPatch 路线，系统级 Hook 的具体实现不在讨论范围内。