Zygisk Next: a standalone Zygisk implementation for KernelSU and Magisk

Zygisk without depending on Magisk's copy of it

Zygisk Next is described in the repository description as a standalone implementation of Zygisk, and the documentation spells out what that means in practice: it provides Zygisk API support for KernelSU, and it acts as a replacement for Magisk's built-in Zygisk.

That is the whole point of the project. Zygisk is the mechanism that lets a module inject itself into the app process space rather than running as a separate app, and until now the usual way to get that API was to install Magisk and accept Magisk's implementation of it. Zygisk Next removes that dependency, which matters for two audiences. The first is KernelSU users, who run a different root solution and had no Zygisk API to build against. The second is Magisk users who would rather run a smaller, independent implementation than the one bundled with their root manager.

The implementation is C, and the repository is deliberately small: README.md, docs/, module.yaml and zygisk_next_api.h, plus a .github directory. That header file is the API surface for anyone writing a module, and the documentation points to a separate sample repository, ZygiskNextModuleSample, for example usage. The interface between the framework and a module is therefore a documented C header rather than a Java API, which shapes who can actually target it.

Version floors decide whether it runs at all

The requirements are stated as a compatibility matrix, and they are strict enough to read before anything else.

For KernelSU, the minimum KernelSU version is 10940 and the minimum KernelSU Manager, ksud, version is 11575. For Magisk, the minimum version is 26402 and the built-in Zygisk must be turned off. There is also a general requirement that no multiple root implementation is installed, which is the same constraint any root setup imposes.

The Magisk line is the one that catches people out. Turning off Magisk's built-in Zygisk is a prerequisite, not a recommendation, so an installation with both the built-in Zygisk and Zygisk Next active is not a supported configuration. The KernelSU line also pairs two version numbers rather than one, which tells you the framework talks to the KernelSU manager as well as to the kernel module, so a manager that is older than the required build will not do even if the kernel side is new enough.

Nothing in the repository describes what happens on a mismatch. There is no compatibility table for intermediate versions and no fallback mode, so the sensible check is the version list itself before you flash anything.

A native API, and a separate path for HyperOS

Zygisk Next provides an API for injecting into init-oriented processes, and the details live in zygisk_next_api.h in the repository root. Example usage is in the linked sample project, which is the reference a module developer should start from.

Alongside that, the project documents support for application callbacks for HyperOS Rust Runtime in docs/hyos_runtime.md. Two properties of that API are stated explicitly and both matter. It is a native-only API, and it does not provide ART or JNI compatibility to regular Zygisk modules. So a module written against it cannot be reused as an ordinary Zygisk module, and a module written the ordinary way will not reach the HyperOS callbacks. The two surfaces are separate code paths rather than one API with an extra feature.

That constraint is worth weighing before choosing a target. If your module is a Java or Kotlin Xposed-style module that relies on hooking ART methods, the HyperOS runtime path is not for you, and the regular Zygisk API header is the relevant document. If your module is native code and your users are on HyperOS, the native callbacks are the reason to pick this implementation at all.

No installation steps are given, so the flashing path is on you

Here the documentation stops. The project notes contain requirements, the API pointer, the sample project, the translation note and the licence, but no installation instructions. There is no command to run, no recovery procedure, no zip to flash and no documented way to uninstall.

What the repository does show is the shape of the artefact. A module.yaml file sits at the top level, which is the descriptor format used by root frameworks for a flashable module package, and the top level contains docs/ alongside the header. The WebUI mentioned in the translation note is a user interface inside the module, and its translations are contributed through pull requests to a separate i18n branch rather than to main, which is a detail that tells you the translation workflow is decoupled from the code branch.

The honest reading is that installation here follows the standard procedure for a root module package on your chosen framework, and this repository does not document it beyond publishing the module. If a project does not tell you how to install it, that is a cost you should price in rather than a gap you can paper over with a tutorial elsewhere.

The licence forbids modification, redistribution and reuse

This is the sharpest fact in the repository, and it changed. The copyright notice states that Zygisk Next, starting from version v4-0.9.2, is no longer under the GPL-3.0 licence. Instead, all rights to the software are reserved by the owner. Copyright is attributed to the Zygisk Next developers for 2024 to 2026.

Four conditions follow. The software may not be modified in any way, which includes changing, adding or removing any part of its code or functionality. It may not be redistributed in any form, including renaming, selling, or including it as part of another project. No part of it may be extracted and submitted to other projects, and the text is explicit that this covers code snippets, functions and released binaries. Finally, a fork created before the licence change may not claim to be an official or unofficial successor, including any use of the name, branding or reputation to imply a connection.

This is a source-available licence in name only for most practical purposes: you can read it, and you can run the published binary. Compare that with the earlier GPL-3.0 terms, under which modification and redistribution were permitted. Note also the version mismatch: the licence change is tied to v4-0.9.2, a numbering scheme from before the current v1.5.x releases, so the terms predate the version line you would actually install. The repository licence field is not filled in, so that statement is the authoritative text here.

Release pace and what a dependency on it costs

The repository is not archived and the last push was on 2026-10-13, the same day as release v1.5.2. The recent history is three releases inside about a month: v1.5.0 on 2026-09-20, v1.5.1 on 2026-10-12 and v1.5.2 on 2026-10-13. Point releases arriving days apart suggests active work on a stable 1.x line.

The cost of depending on it is different from the cost of depending on a normal open source library, and it comes from the licence rather than from the API. If you write a module that needs Zygisk Next, you are building on a binary you cannot patch, cannot vendor and cannot redistribute as part of your own project. That rules out several ordinary workflows: bundling it into a custom ROM or a rooted-device image, shipping it with your own installer, or maintaining a private fix for a device-specific problem.

The module ecosystem is the mitigation. Because the API is a header and there is a sample module, a module author can develop against the documented interface and target whichever implementation the user has installed, which keeps the coupling on the API surface rather than on the binary. That is workable, but it does mean you are targeting a moving implementation whose licence can change again, in a repository whose licence field is still unset.

Editorial conclusion

Adopt Zygisk Next if you write Zygisk modules and want them to work on a KernelSU device or on Magisk with built-in Zygisk disabled, and you are prepared to treat the binary as a closed dependency you cannot patch. Skip it if your plan involves forking the implementation, vendoring it into a build, or shipping it to end users, because those are exactly what the licence forbids. Verify first the minimum versions on your device, KernelSU 10940 with ksud 11575, or Magisk 26402 with built-in Zygisk off, and that only one root implementation is installed.

Frequently asked questions

Official sources

1. Issues
2. LSPosed/ZygiskNext on GitHub
3. README
4. Releases