本地与集成模式

NPatch 修补时要二选一：用 --manager（本地模式）或 --embed（集成模式）。两种模式互斥，CLI 上不能同时带。差别在于模块从哪里来、修补后的 APK 能不能独立运行。

本地模式（--manager）

为未嵌入模块的应用打修补。作用域由 NPatch 管理器动态配置，无需重新修补；运行时可短暂使用最后一次同步的缓存。

运行时，被注入的 Xposed 环境会按目标应用包名向 NPatch 管理器（包名 top.nkbe.npatch）取得模块列表与作用域。作用域仍以管理器数据库为准，不会因为加入 Remote API 而改成由目标应用自行决定。

加载器会先连接 Manager Service；若 Binder 暂时不可用，会改用管理器的 ConfigProvider 查询作用域。Provider 也不可用时，才沿用目标应用上次成功同步的模块缓存。因此管理器不必常驻前台，但要新增、移除模块或同步最新配置时仍需安装并可被系统访问。

修补后的 APK 自己包含启动所需文件：

• assets/npatch/loader.bin（loader dex）
• assets/npatch/so/<arch>/libnpatch.so（arm64-v8a 与 x86_64）
• android.permission.QUERY_ALL_PACKAGES（用于解析已安装模块与管理器）

loader 与原生核心来自修补后的 APK，不再从 Manager APK 临时提取。Manager 只负责模块、作用域、Remote 数据与管理操作。

示例

java -jar jar-v<verName>-<verCode>-release.jar --manager target.apk

适合的场景

• 自己的设备、长期使用
• 想随时调整模块或作用域，不想为了换模块重新修补
• 一次修补多个应用，由同一个管理器统一管理
• 需要更高的签名绕过等级（Extreme / Seccomp 只能在这个模式用）

限制

• 设备上必须有 NPatch 管理器
• 管理器临时不可用时可以沿用最后一次成功同步的模块缓存，但新的作用域、模块路径与 Remote 数据不会更新
• 修补后 APK 与管理器的版本可能需要对齐，太旧的管理器可能不认得新修补

集成模式（--embed）

修补 App 并内建模块。经修补的应用可以在没有管理器的情况下独立运行，但不能动态管理配置。此模式适用于需要在未安装 NPatch 管理器的设备上运行的应用。

修补时把模块 APK 一起打进输出文件，模块存放在 assets/npatch/modules/<package>.apk。输出 APK 自包含，启动时 Loader 直接从 assets 加载模块，不依赖管理器提供模块列表或作用域。集成模块的 Remote 数据默认保存在目标应用自己的数据目录中，因此不同目标应用之间不会共享同一份配置。

修补时会在 manifest 加上对应的 Xposed metadata（xposedmodule、xposeddescription、xposedminversion）。

示例

java -jar jar-v<verName>-<verCode>-release.jar --embed module1.apk --embed module2.apk target.apk

--embed 可以重复，每个模块一个。

适合的场景

• 要把修补后的 APK 给别人装，对方没有管理器
• 需要在很多台设备分发同一份修补
• 模块组合固定，不需要动态切换

限制

• 模块版本固定在修补时的版本，要更新模块就得重新修补
• 输出 APK 体积会变大（内含所有模块 APK）
• 不能在运行时关掉某个内嵌模块
• 签名绕过上限为 High（2）：Extreme 与 Seccomp 不允许在这个模式下使用

对照表

项目	本地模式 (--manager)	集成模式 (--embed)
是否需要管理器	配置与同步需要；运行时可短暂使用缓存	否
模块从哪里来	设备上的管理器	APK 内嵌的 assets
动态切换模块	可以（在管理器里）	不行（要重新修补）
可独立分发	不建议；缺少管理器时只能使用已有缓存	是
修补后 APK 体积	较小	较大（含模块）
签名绕过上限	Seccomp（4）	High（2）
CLI flag	--manager	--embed <module.apk>
互斥	不能与 --embed 同时用	不能与 --manager 同时用

两种模式可以混用吗

同一台设备可以同时有本地模式修补的 A 应用、集成模式修补的 B 应用，互相不影响。管理器只看得到本地模式的应用，集成模式的完全独立运作。

Remote API 在两种模式中的差异

本地模式下，模块 UI、Legacy、API 101 与 API 102 都会汇入管理器中的同一套 NPatch Remote Store。管理器的 top.nkbe.npatch.remote Provider 会验证调用 UID、模块包名与作用域，避免未授权应用取得 Binder。

集成模式没有管理器端点，会使用目标应用自己的 host-local Store。相同模块被内嵌到多个应用时，每个应用都会有独立的 Remote Preferences、Remote Files 与原生库快取，这是 Android 数据目录隔离下的预期行为。

跟其他修补选项的搭配

无论哪种模式，下面这些选项都可以照用：

• --sigbypasslv 0~4 — 签名绕过等级（CLI 默认为 Basic；管理器界面默认为 High；集成模式 ≤ 2）
• --useMicroG — 重定向 GMS 请求至社区版 MicroG（如 ReVanced GmsCore），会在 manifest 加 fake-signature metadata 与 FAKE_PACKAGE_SIGNATURE 权限
• --injectdex — 对那些需要孤立进程的应用（比如浏览器的渲染引擎），请勾选此选项以确保正常运行
• --provider — 注入文件选择器（来自 MT 管理器），以在没有 Root 权限的情况下管理 data 目录的文件
• --debuggable — 标记应用为可调试，方便调试
• --allowdown / -r — 将打包应用的版本号改成 1，允许以后降级安装

完整 CLI 选项看 使用说明。本地模式底下管理器能做的事看 管理器与 Shizuku。

怎么选

简单的判断：

• 自己用、会调整模块 → 本地模式
• 要分发给别人 → 集成模式
• 一台设备用，模块组合固定，懒得装管理器 → 集成模式
• 模块会频繁更新 → 本地模式（集成模式每次更新都要重新修补）
• 应用有强签名校验，需要 Extreme / Seccomp 等级绕过 → 只能本地模式