使用说明
NPatch 提供两个东西：
jar-v<verName>-<verCode>-release.jar— 跨平台修补工具，纯 Java，Windows / macOS / Linux 任一平台只要有 Java 就能跑manager-v<verName>-<verCode>-release.apk— Android 端的 NPatch 管理器，本地模式才需要
两者通常一起发布。建议先读 什么是 NPatch，理解两种模式的差别，再回来看怎么用。
获取方式
- 稳定版：GitHub Releases
- Canary 构建：GitHub Actions 上
open-source分支的最近 build - Debug 构建：只在 GitHub Actions 上提供
- 官方频道：Telegram
文件名格式
Release 页面上看到的文件名长这样：
jar-v1.0.5-639-release.jar
manager-v1.0.5-639-release.apk对应规则 <artifact>-v<verName>-<verCode>-<variant>.{jar,apk}：
verName— 版本名称（例如1.0.5）verCode— 版本号（例如639）variant— 构建类型，release（稳定）或debug（GitHub Actions 才有）
环境需求
| 项目 | 需求 |
|---|---|
| 修补工具运行环境 | Java（运行 jar-v<verName>-<verCode>-release.jar） |
| 平台 | Windows / macOS / Linux 任一即可 |
| Android 版本 | 修补后的应用需要 Android 9 (API 28) 以上 |
两种使用方式
方式一：用管理器 App（推荐）
把 manager-v1.0.5-639-release.apk 装到设备上，从界面选择要修补的应用，修补完成后直接安装，全程在设备上完成。对大多数用户来说这是最方便的方式。
更多管理器能做的事情看 管理器与 Shizuku。
方式二：用 jar 修补
适合批量修补、自动化或 CI 场景。把目标 APK 丢给 jar，产出 <原名>-<NPatch versionCode>-npatched.apk。
java -jar jar-v1.0.5-639-release.jar [options] <apks...>最小可用示例（本地模式，默认签名绕过 Basic）：
java -jar jar-v1.0.5-639-release.jar --manager target.apk集成模式（内嵌一个或多个模块）：
java -jar jar-v1.0.5-639-release.jar --embed module1.apk --embed module2.apk target.apk下面示例使用 jar-v1.0.5-639-release.jar 作为示范文件名，请以你实际下载到的版本为准。
CLI 选项
对应 top.nkbe.npatch.patch.NPatch 中的 @Parameter 声明。
| 选项 | 说明 | 默认 |
|---|---|---|
<apks> | 要修补的 APK 路径（位置参数，至少一个） | — |
-h, --help | 显示说明 | — |
-o, --output | 输出目录 | .（当前目录） |
-f, --force | 覆盖已存在的输出文件 | 关 |
-p, --newpackage | 修补新包名 | 不改 |
-d, --debuggable | 应用可调试 | 关 |
-l, --sigbypasslv | 签名绕过等级 0–4（见下） | 1 |
--injectdex | 注入加载器 Dex（孤立进程需要，例如浏览器渲染引擎） | 关 |
--provider | 注入文件选择器（来自 MT 管理器），管理 data 目录文件 | 关 |
--installerSource | 设置原始安装来源字符串 | — |
--useMicroG | 强制启用 MicroG 支持，重定向 GMS 请求至社区版 MicroG | 关 |
--outputLog | 将 Xposed 与框架启动日志输出到 Media 目录 | 开 |
-k, --keystore | 自定义签名密钥库，需要 4 个值：path storePass alias aliasPass | — |
-npa, --npatch-keystore | 用内建 NPatch 密钥库 | — |
-fpa, --fpa-keystore | 用内建 FPA 密钥库 | — |
--manager | 启用本地模式（与 --embed 互斥） | — |
-r, --allowdown | 覆盖版本号为 1，允许以后降级安装 | 关 |
-v, --verbose | 详细打包日志 | 关 |
-m, --embed | 启用集成模式并指定模块 APK，可重复（与 --manager 互斥） | — |
互斥规则
下列规则由 CLI 解析时直接拦截：
--manager与--embed不能同时使用-k不能与-npa或-fpa同时使用-npa与-fpa不能同时使用- Extreme（3）和 Seccomp（4）必须搭配
--manager；集成模式（--embed）下，sigbypass 上限为 High（2）
签名绕过等级
直接引用 NPatch 界面中的官方说明：
| 等级 | 名称 | 说明 | 集成模式可用 |
|---|---|---|---|
| 0 | None | 不进行任何处理 | 是 |
| 1 | Basic | 增加 Java IO 与 Native openat / openat64 重定向，让签名相关的文件读取改为访问原始 APK | 是 |
| 2 | High | 基于 Basic，恢复原始 AppComponentFactory，并 hook getPackageArchiveInfo 与 hasSigningCertificate 等更严格的校验路径 | 是 |
| 3 | Extreme | 基于 High，hook PackageInfo(Parcel) 构造函数，覆盖 Binder 反序列化获取签名信息的路径 | 否（需 --manager） |
| 4 | Seccomp | 在 ARM64 上启用 seccomp v2 过滤与 trusted thread 文件重定向，参考 FunPatchApp 的实现方案 | 否（需 --manager） |
实际使用：先试 1，不行再往上调。等级越高不代表越好，部分应用在高等级下反而会异常。
安装修补后的 APK
由于签名不同，安装前需要先卸载原应用。确保你已备份好个人数据。
WARNING
卸载会清掉应用数据。重要的东西先在原版里备份，或用 ADB 备份。
本地模式的后续步骤
- 安装
manager-v*-release.apk（包名top.nkbe.npatch，如果还没装） - 安装修补后的 APK
- 打开管理器，找到该应用，加入要加载的 Xposed 模块与作用域
- 启动应用，模块就会生效
集成模式的后续步骤
装完修补 APK 就可以直接用，模块已经放在 assets/npatch/modules/<package>.apk 里。要换模块需要重新修补。
进阶：自定义密钥库
默认会用内建密钥库（不指定时走 -npa 路径）。如果你有自己的密钥库：
java -jar jar-v1.0.5-639-release.jar -k mykey.jks storePass myalias aliasPass --manager target.apk四个位置参数顺序：密钥库路径、密钥库密码、别名、别名密码。内部使用 BKS 格式加载，并启用 V2 签名。
管理器内也有自定义密钥库设置，界面里可以验证密钥库类型、密码、别名是否正确。