什么是 NPatch

NPatch 是一款基于 Vector 核心的免 Root Xposed 框架。

它是专为免 Root 环境设计的现代化 Xposed 模块注入与应用修补工具。NPatch 能在免 Root 环境中，通过修改 APK 文件注入 Xposed 加载器：本地模式需搭配管理器动态加载并管理模块与作用域，但使用时无需保持管理器处于后台运行；集成模式则将模块直接内嵌至目标应用中，适合无管理器的设备独立运行。

新版本的 core 子模块指向 HSSkyBoy/Vector，这是 NPatch 新版的运行核心，后续能力都建立在它之上。

它怎么运作

修补过程大致上：

1. 用 apkzlib 打开目标 APK
2. 改写 AndroidManifest.xml，把 appComponentFactory 替换为 top.nkbe.npatch.metaloader.LSPAppComponentFactoryStub
3. 注入 meta-loader dex（assets/npatch/metaloader.dex）
4. 无论使用本地模式还是集成模式，都会把 loader dex 与 libnpatch.so（arm64-v8a 与 x86_64）写进修补后的 APK；应用启动不再依赖读取管理器 APK
5. 签名绕过等级 ≥ Basic 时，把原始 APK 以嵌套 zip 嵌进去（assets/npatch/origin.apk），运行时可以回读原签名
6. 用密钥库重新签名，输出 <原文件名>-<NPatch versionCode>-npatched.apk

运行时，被改写的 appComponentFactory 会按需启动 Xposed 环境，再把组件创建交还给应用原本的 component factory。启动失败会写入 cache/npatch/bootstrap_state.json，并尽量让原应用继续启动，而不是因为静态初始化异常直接崩溃。

输出文件名后缀的版本号是 NPatch 自己的 LSConfig.VERSION_CODE，不是原 APK 的 versionCode。

模块 API 与运行能力

NPatch 目前使用同一套 Vector 运行时处理不同世代的模块，不采用为每个 API 版本分别放入一份 wrapper dex 的做法：

• Legacy 模块继续支持传统 assets/xposed_init 与 XSharedPreferences
• 现代模块支持 libxposed API 101 与 API 102 生命周期
• API 102 单入口模块支持热重载；模块升级后可由管理器请求目标进程重新加载，并返回明确结果
• Legacy、API 101 与 API 102 共用 NPatch Remote 数据层；Remote Preferences 支持读写、删除与变更通知，Remote Files 支持列出、打开与删除

本地与集成（两种使用模式）

NPatch 有两种互斥的修补模式：

• 本地模式（--manager）：模块与作用域仍由管理器配置。启动时优先使用 Manager Binder；连接失败时会尝试 ConfigProvider，并可沿用上次成功同步的模块缓存。要新增、移除模块或同步 Remote 数据，仍需要管理器。
• 集成模式（--embed）：修补 App 并内建模块。经修补的应用可以在没有管理器的情况下独立运行，但不能动态管理配置。此模式适用于需要在未安装 NPatch 管理器的设备上运行的应用。

两个 flag 互斥，CLI 上不能同时带。详细差异看 本地与集成模式。

系统需求

• Android 9 (API 28) 或更高
• 上限大致跟 JingMatrix/Vector 一致
• 修补工具本体：jar-v<verName>-<verCode>-release.jar（纯 Java，跨平台，Windows / macOS / Linux 都能跑，需有 Java 环境）

适合的场景

• 设备没解 Bootloader、不想或无法 Root
• 只想针对特定用户应用注入 Xposed 模块
• 在多台设备分发同一份修补

不适合的场景

• 需要修改 system server、framework、系统应用 — NPatch 只能处理用户应用
• 目标应用做了强完整性检查、SafetyNet / Play Integrity 严格验证的场景，例如金融或部分手游
• 加固后的 APK（dex 加密、壳保护），通常无法直接修补

接下来

• 直接动手：使用说明
• 用管理器与 Shizuku：管理器与 Shizuku
• 两种模式怎么选：本地与集成模式
• 修补踩坑：常见问题