NPatch: a rootless Xposed framework built on LSPosed, packaged as a jar or an Android manager

The problem NPatch solves: Xposed hooks without root

Xposed style modification normally requires a rooted device, because the framework has to load itself into every app process. NPatch takes the other route. The README describes it as a "Rootless implementation of LSPosed framework, integrating Xposed API by inserting dex and so into the target APK." Instead of hooking the whole system, it rewrites a single app's package so that the framework travels inside that app.

The audience is therefore narrow and specific. You need an Android device you are willing to run unsigned or re-signed APKs on, a target app you want to modify, and no requirement that the modification apply system wide. If you are patching one app, the model fits. If you want a hook to apply to every process on the device, this is the wrong architecture, because nothing is installed at the system level.

The project is a fork. The credits list Xpatch as the fork source, LSPosed as the core framework, and Apkzlib as the repacking tool. NPatch is a reimplementation of LSPatch on that stack, and the default branch is named miuix. The topics on the repository are lspatch, rootless and xposed, which is an accurate summary of what it does.

How the patch pipeline works: dex, .so and APK repacking

The mechanism is offline repacking rather than runtime injection. The README states that NPatch integrates the Xposed API by inserting dex and shared objects into the target APK. Apkzlib, credited as the repacking tool, is the component that writes the modified archive back out. The repository layout reflects this split: there are top-level directories named patch, patch-loader, meta-loader, core, manager, jar, apkzlib, share and remote-api.

That layout suggests a staged pipeline. A patch stage produces the modified artifacts, loader modules carry them into the app at startup, and the manager app drives the process on-device. The README does not document the internal interfaces of those modules, so the exact contract between patch-loader and meta-loader is not something a reader can confirm from the documentation alone.

The release notes in the README describe two hook-stack fixes. LSPlt "avoids a transient unmapped GOT/PLT region while installing hooks," which the README says prevents dex2oat and zygote crashes on affected 32-bit Android 10 devices. LSPlant "initializes CloseGuard for synthetic DexFile objects on Android Nougat and below, and aligns hook trampolines correctly." Both are low-level ART concerns, which tells you the project is maintained at the level of the hooking runtime, not just the packaging wrapper.

Installing NPatch and patching your first APK

There are two documented paths. The jar path runs on a desktop JVM. The README gives a single command for it: download npatch.jar, then run it. The project publishes stable builds on the GitHub Releases page, canary builds through GitHub Actions, and debug builds only through GitHub Actions.

java -jar npatch.jar

Running that starts the jar's own workflow. The README does not list the jar's command line flags or subcommands, so treat the invocation above as the entry point and expect the tool itself to guide the rest.

The second path is the manager app, which is the one most users will want. Download manager.apk, install it on the Android device, and follow the instructions inside the app. The README does not spell out those steps, so the manager is the authority on the patching flow.

# On the Android device, after installing manager.apk:
# open the NPatch manager and follow its in-app instructions

Supported versions matter before you start. The README gives Android 9 as the minimum, and says the maximum is "in theory, same with JingMatrix/LSPosed." That wording is a hedge: the upper bound is inherited from another project rather than tested here, so a device on a very recent Android release is not a guaranteed target.

Where NPatch breaks down

The most obvious limitation is the one the README leaves out. It documents no rollback, no uninstall path for a patched APK, and no way to restore the original package. If a patch produces an app that misbehaves, the documentation offers nothing about reversing it. You should assume you need your own copy of the original APK before patching, because the project does not tell you otherwise.

The second constraint is the upper Android bound. "In theory" is doing real work in that sentence. A framework that hooks ART internals is sensitive to ART changes, and inheriting a version ceiling from LSPosed means NPatch's own compatibility on newer releases is not independently stated. The README's own stability notes are evidence of how fragile this layer is: the LSPlt fix exists because a transient unmapped GOT/PLT region during hook installation crashed dex2oat and zygote on 32-bit Android 10.

Third, the documentation is thin on the jar. It gives one command and no flags, no output description, and no indication of what the jar expects as input. Anyone planning to script the patching step will be reading the source rather than the README.

Finally, rootless does not mean unconstrained. Because hooks live inside a repackaged APK, the app must be re-signed, and any signature check the target app performs will see a different signer. NPatch cannot work around that, and the README does not claim it does.

NPatch compared with LSPatch and LSPosed

LSPatch is the direct reference point, and the relationship is stated plainly: NPatch is a reimplementation of LSPatch on an LSPosed base, and the repository carries lspatch as a topic. Both take the rootless route of modifying a target APK rather than installing a system-wide framework, so the difference is not the approach but the lineage and the maintenance. NPatch credits Xpatch as its fork source and LSPosed as its core framework, and its README documents specific hook-stack work on LSPlt and LSPlant.

LSPosed is the other comparison, and here the approaches genuinely diverge. LSPosed is a rooted framework: it installs at the system level and its hooks can apply across processes. NPatch inverts that. It trades system-wide reach for not needing root, which means per-app patching, per-app re-signing, and no ability to hook an app you have not patched.

That trade-off decides the choice for you. If you have root and want broad coverage, a rooted framework matches the requirement and NPatch does not. If you do not have root, or you only care about one or two apps, the rootless model is the only one available, and NPatch is one of the implementations of it.

Licence and the cost of keeping up

NPatch is licensed under the GNU General Public License v3, stated in the README and in the repository's LICENSE file. GPL-3.0 is a copyleft licence, so distributing a modified version carries source disclosure obligations. What that means for a repackaged third-party APK is a question for a lawyer, not for this article; the practical point is that the licence is not permissive and the project does not offer an alternative.

On maintenance, the repository is not archived. The last push was on 2026-09-28, which is the same day as the most recent activity in the release list context, and the newest release listed is v1.0.8, dated 2026-09-27. Before that come Canary-762 on 2026-08-21 and v1.0.7 on 2026-08-14. That cadence, with canary builds between stable releases, means upgrade cost is mostly about watching which channel you are on: stable users move on release tags, canary users take whatever GitHub Actions produced.

The hidden upgrade cost is the patched apps themselves. NPatch does not patch the system, so an upgrade to NPatch does not automatically refresh the apps you already patched. Nothing in the README says patched APKs are updated in place, so you should expect to re-patch after a framework upgrade. Budget for that rather than assuming patches carry forward.

Editorial conclusion

NPatch is aimed at Android users on Android 9 or newer who want Xposed style hooks without root, and at developers who want to inspect the patch pipeline through npatch.jar. It is the wrong tool for anyone who needs a documented rollback path, since the README does not describe one, and for anyone who cannot accept GPL-3.0 obligations on the patched output. Before adopting it, check the releases page for the newest build and confirm the target app's Android version falls inside the supported range.

Frequently asked questions

Official sources

1. 7723mod/NPatch on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases