Shizuku-Next: a Shizuku fork with more start methods and a manager console

Same package name, same API, different signing key

Shizuku-Next is described as an enhanced fork of Shizuku that lets apps use system APIs through ADB or root, and its lineage is spelled out in the About section. It continues the development of thedjchi's Shizuku fork, which is itself based on the original RikkaApps/Shizuku.

The compatibility promise is simple and important: it keeps Shizuku's package name and API, so compatible apps continue to work. For a user with a set of apps that rely on Shizuku, that is what makes the fork a drop-in in behaviour even though it is not a drop-in in installation.

And here is the catch, which the README puts in a block of its own. The fork uses a different signing key, so the official Shizuku app or thedjchi's fork has to be uninstalled before Shizuku-Next is installed. There is a second detail in the same warning: a server started by the previous app may remain active until it is stopped or the device is rebooted. That is worth understanding, because a stale server holding the privileged port can make the new install look broken in a way that has nothing to do with the new install.

The practical sequence is therefore: uninstall, reboot if the previous service does not stop, install, then start it again with whichever method the device supports. The repository has a Releases page and a Crowdin project for translations, with translation details in docs/translations.md, and the project is free with no ads.

The licence is Apache-2.0, and the last push was on 2026-10-20, with the most recent releases being v14.0.27-next on 2026-10-18, v14.0.27-beta-next on 2026-10-14 and v14.0.26-next on 2026-10-13.

Starting the service is where most of the engineering went

The features are grouped under starting and reliability, and the grouping is telling: the hard part of Shizuku has always been getting the service to run with the privileges an app needs.

The start methods are wireless debugging, USB debugging, root, and the Samsung system UID where supported. On top of that the fork automates the fiddly part of wireless debugging: it handles the pairing automatically, and on supported devices it reads the pairing code for you. That removes the most tedious step in the whole workflow, which is reading a six digit code off a phone screen and typing it into a terminal.

The reliability features are all about the service staying up. There is an optional start on boot, a watchdog that restarts it, automatic recovery, and configurable restart timing. There is a TCP mode, recovery of the USB port after a reboot, and an experimental startup without Wi-Fi for the cases where the wireless path is blocked. A failure log and clearer startup status are also listed.

And then there is the stealth option, an optional mode to hide the Developer options and ADB settings. This is a different category of feature from the others, because it is about what a user or an observer can see on the device rather than about reliability, and it is the kind of thing worth thinking about twice.

The README is direct about the limits: some features are experimental or device dependent, and root, the Samsung system UID and the no-Wi-Fi startup method are not available on every device. The requirements section repeats the same point per method, and the wireless debugging path needs Android 11 or newer while the app itself runs on Android 7.0 or newer.

The manager is an Android administration console

The manager application is the part that makes this fork feel like a different product rather than a rebuild of the same service.

The interface is Material 3, split into Home, Apps, Modules, Labs and Settings. Inside it you manage Shizuku access, app permissions, app ops, battery settings and app network access, with a fallback to the platform's own firewall API on ROMs whose connectivity command is missing, which is a real portability detail for anyone building on a vendor's Android skin.

Beyond that there is app inspection and launching activities, a built-in shell, a log viewer, a file browser and an app installer. You can manage saved Wi-Fi networks and export and import their credentials. You can force dark mode and hide selected device settings for chosen apps. Batch permission changes, searchable app lists and device information are there too, and the automation story is handled through intents and status broadcasts, with Tasker named explicitly as a consumer.

The Wi-Fi credential export deserves a mention. It is a genuinely useful feature for anyone moving a device between networks, and it is also the most sensitive thing in the list, since the saved networks carry passwords. The README does not say what protects the exported file, so treat it as you would any credential dump.

The Labs section is where the experimental features live, which is a reasonable convention: a user can try the newest thing without it being mistaken for the stable path.

Modules are an extension model, and the trust warning is not optional

The module system is the most novel feature, and the README labels it experimental.

The ADB module support covers module actions, services and a WebUI, and there is a document in the repository, docs/adb-modules.md, that explains the format: the module.prop file, the environment a script runs in, the WebUI bridge, how trust works, and how a module is discovered. In other words, a module is a package with metadata, a script, and optionally a web interface that talks back into the app through a window.Shizuku bridge.

The credits explain where the idea came from. The ADB modules feature, including the module format, the actions and services, and the WebUI bridge, comes from kerneldroid's Nightzuku project. The published module API and the guide that this app's module support is written against, along with the module catalogue it searches, come from Shevery. ShizuWall is credited as well, though the list is cut off in the README.

That provenance also explains the trust question. A module is code that runs with the privileges of the Shizuku service, and the catalogue is fetched from GitHub, so the supply chain is the internet and the runtime privilege is high. The README's advice is the only sane one: only install modules and scripts you trust. The modules list is read from GitHub, which is also why the app needs internet access beyond the wireless debugging connection.

The rest of the compatibility list is more mundane and also useful: stealth mode and in-app updates, an Android TV and VR friendly interface, and MediaTek compatibility fixes for some devices.

Privacy claims and the privilege question

Two separate topics sit under the headings of privacy and developer guide, and both need reading before installation.

The privacy section lists what the app does not do: no tracking or analytics, no telemetry or proprietary libraries, and no Google Play Services dependency, which is the point of the whole Shizuku design, since apps that use system APIs through a service rather than through Google services can do so on devices without them. It also claims open source code and reproducible builds, and then states what the internet access is for: wireless debugging connections, checking and downloading GitHub updates, and the module lists, which are read from GitHub. That is a narrow and specific list, which is the kind of privacy claim worth having.

The app does request permissions, and the README is explicit about which: notifications, background services, wireless debugging and boot startup.

The developer guide carries the warning that matters most in practice. Shizuku may run with different privileges depending on the start method, so you must check the server UID and the permissions before assuming you have root. A start method that gives the service shell access through ADB and a rooted start are not the same thing, and code that assumes root will fail in one and work in the other. The guide also recommends preferring ShizukuBinderWrapper over calling transactRemote directly, and the API documentation and a demo project live in the separate Shizuku-API repository.

Combined with the module trust warning, the message is consistent: this is a component that other apps will call with a higher level of privilege, and both the install path and the modules you add are the places to be careful.

Building from source, and a release train that ships every few days

The build instructions are short, and the release history shows a project that ships continuously.

The clone needs the submodules, and the debug build is a single Gradle task:

git clone --recurse-submodules https://github.com/rushiranpise/Shizuku-Next.git
cd Shizuku-Next
./gradlew :manager:assembleDebug

The release build is the same with a different task:

./gradlew :manager:assembleRelease

The README adds a debugging detail that is easy to miss: the debug task builds a debuggable server, and when debugging shizuku_server in Android Studio you should enable the Always install with package manager option in the run configuration. That setting exists because a debuggable server has to be reinstalled on every run for the changes to take effect.

The repository layout shows the structure of the project: separate directories for the api, the common code, the manager application, the server, the shell, a starter and a stub, alongside a ci/ directory, docs/, a build.gradle.compileSdk36 file and a signing.gradle. The presence of signing.gradle and a separate compile SDK configuration file are the fingerprints of a fork that has to keep building against the original's structure while adjusting its own toolchain.

The release cadence is the other thing to note. Three of the listed releases fall in the same week in October 2026, two of them carrying the next suffix, which is a project that rebuilds and republishes continuously rather than cutting a monthly version. The trade for users is that fixes arrive quickly and breakage is possible, and the contribution guide reflects a normal open source flow: fork, branch, test, commit, open a pull request.

Editorial conclusion

Adopt Shizuku-Next if you already use Shizuku and want the extra start paths, the module system and the manager tooling without giving up the existing apps that depend on the API. Do not adopt it as a drop-in upgrade, because the fork uses a different signing key and the previous app has to be uninstalled first, and treat the module feature as a security decision rather than a feature, since the README's own advice is to install only modules and scripts you trust. Before you install, work out which start method your device supports, check the server UID afterwards instead of assuming root, and read the privacy section for how much of your Wi-Fi configuration the credential export puts on the device.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rushiranpise/Shizuku-Next on GitHub