Sui gives Android apps a root Binder without a su binary

A shell is the wrong interface for an app that needs framework data

The problem Sui addresses is the mismatch between how a root shell works and how an Android app works. The README makes the argument through a concrete example. An app wants the list of installed applications, which in normal Android is a call to PackageManager#getInstalledApplications, and that call is really an inter-process communication exchange between the app process and the system_server process, with the Android Framework hiding the details. Over a root shell the same thing means running pm list, and the README lists why that is painful. The output is text-based, so there is no structured PackageInfo to work with and you have to parse it. It is slow, because running a command means starting a new process and PackageManager#getInstalledApplications still runs inside that pm list. And the ability is limited, because the commands only cover a small part of the Android API surface. Sui is a way to get the first option back for an app that already has root.

Two capabilities: direct framework calls and a service under root

The implementation is described as providing Java APIs, namely the Shizuku API, for root and shell apps, and it mainly provides two abilities. The first is to use Android Framework APIs directly, almost as if calling system APIs from Java as root or shell. The second is to start an app-defined AIDL-style Java service under root or shell, which is what makes the first possible for a client app, because the privileged process has to exist before the app can bind to it. The README also points at a design choice that has practical consequences: Sui does not add binaries to PATH and does not install a standalone manager app. The stated reason is that the project no longer wants to spend a large amount of time fighting apps that detect them, which is the same detection problem that has pushed other root tooling toward invisible implementations. The repository is a Gradle project with api/, module/, template/, ui/ and buildSrc/ directories, plus a .clang-format and the usual Gradle wrapper files.

It is a Zygisk module, not a root solution

The scope boundary is stated in the introduction and worth repeating, because the name invites the wrong assumption. The README says the full implementation of root is far more than su itself, that there is a lot of hard work to be done before it is, and that Sui is not a full root solution. It requires an existing root environment and runs as a Zygisk module. There is also a related note about the historical approach: it is possible to use Java APIs as root with app_process through libraries such as libsu or librootjava, but transferring Binder objects between the app process and the root process is painful, and if you want the root process to run as a daemon, once the app process restarts there is no cheap way to get the Binder of the root process again. That is the gap Sui is built to close, and it is also why the project needs a resident privileged process rather than a command.

Installation means a root manager with a Zygisk implementation

Installing Sui is a matter of flashing it into whatever root environment the device already has. The README says you can install Sui directly in KernelSU or another compatible root manager such as Magisk or APatch, or download the zip from the release page and use Install from storage in your root manager. The requirements are specific about versions. On Magisk it means Magisk 24.0 or newer with Zygisk enabled. On KernelSU or APatch it additionally requires a separate Zygisk implementation, and the README names Zygisk Next, ReZygisk and NeoZygisk as the options. One more condition is easy to miss: SystemUI and Settings must not be added to the Zygisk DenyList, otherwise the injected management UI may not work properly. The note that existing apps supporting only su will not change their behaviour is the compatibility promise the project makes.

The management UI is a shortcut, not a separate app

Since Sui installs no manager app of its own, the interface has to be reachable another way, and the README documents the routes. The simplest is to long press the System Settings icon on the home screen to see the Sui shortcut, and from the top-right menu of the management interface you can add a shortcut to the home screen. There is also a dialer code, entered in the default dialer app, and the module Action button in a supported root manager opens the interface as well. The README notes that on some systems the shortcut may not appear when long-pressing Settings, and that newer versions have removed the feature that automatically prompts to add a shortcut when entering Developer options, to avoid disturbing users. The dialer code itself is worth noting as a literal, since it is the kind of detail that gets documented once and then forgotten:

* Enter `*#*#784784#*#*` in the default dialer app

Permission is a per-UID decision with a global default

The permission model is the part a security reviewer will care about, and it is per UID rather than global. Sui stores explicit permission states by UID, and tapping an app in the management UI selects one of the explicit modes, or you choose Default to remove the explicit rule and inherit the global default set through Modify default value. The global default itself can be Ask, root, shell, Deny or Hide. The explicit modes are Allow root, routing the app to the root backend, Allow shell, routing to the shell backend, Deny, which denies the app from using Sui, and Hide. Hide is the interesting one. When it is enabled, the target app UID is intercepted in the Native Binder execTransact stage, and the Sui bridge transaction is swallowed before it can reach BridgeService and obtain the Sui Binder, so the app never learns Sui exists. Default means no explicit state is stored and the app inherits the current global default, and when that default is Ask the app can connect and request permission through the normal flow.

Options for legacy clients, shell escalation and ADB root

The top-right menu is also where the more unusual settings live, and three of them are worth understanding. Legacy Shizuku support optionally serves the old explicit REQUEST_BINDER broadcast protocol used by older Shizuku clients, and the compatibility hook is bypassed when Shizuku itself is installed, keeping the normal Sui permission and Hide routing rules. Block Shell root, on supported KernelSU versions, marks the Sui shell process before it drops to UID 2000, so that Rish, shell-mode Shizuku API calls, UserService processes and their descendants cannot use KernelSU to escalate back to root. A reboot is required, and if the running KernelSU does not support the required UAPI, Sui disables the option rather than preventing the shell backend from starting. ADB Root offers Off, Enable for next boot once, or Always enable, and also needs a reboot. These options are persisted by the Sui service, and the README asks users to change them in the management UI rather than editing marker files under /data/adb/sui/ by hand.

GPL-3.0, a nightly build, and a project that moved

The licence is the GNU General Public License v3.0, with the LICENSE file at the root, and the README links to Chinese and Japanese versions of the document alongside the English one, which is a reasonable signal about the project's audience. The project originally sat under the RikkaApps organisation, which the homepage in the repository metadata still points at, and the current repository is under XiaoTong6666, which suggests a move of the project between organisations. There is also a note that the name Sui comes from a character, linking to an issue. On releases, the only tagged build is a nightly build from 2026-02-06, so there is no numbered version series to pin to, while the last push to the repository was on 2026-10-19. The repository is a Gradle build with an .idea/ directory, a .clang-format, .gitmodules and a template/ directory that is likely where a new module starts from.

Editorial conclusion

Sui suits an Android developer building a root-aware app that needs structured framework data, such as a package list or a running service, and who can already assume a rooted device with a Zygisk-capable root manager. It does not suit an app whose only privilege need is a single shell command, and it does not suit devices without a compatible root environment, since the README states plainly that Sui requires one. Before adopting, confirm the target root manager and Zygisk implementation, plan for the per-UID permission rules, and note that the only tagged release is a nightly build from 2026-02-06 while the last push to the repository was on 2026-10-19.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. XiaoTong6666/Sui on GitHub