Shevery: a Material 3 Shizuku fork that also manages ADB modules
Shevery - Modernized Android manager with Jetpack Compose, Material 3, and compatibility enhancements.
At a glance
- What is it?
- Shevery is a fork of RikkaApps' Shizuku that modernizes the manager with Jetpack Compose and Material 3, targets Android 16 and 17, and adds an ADB modules system with policy gates, a module catalog and an AI-assisted shell console. The mechanism is unchanged and battle-tested: a server run with root or ADB bridging apps to higher-permission system APIs.
- Who is it for?
- Shevery fits Android power users who already run Shizuku-style privileged tooling and want an ADB module manager with policy controls, a Material 3 interface and an AI-assisted command console, and who accept a signature-changing fork on current Android versions. It does not fit anyone who needs the canonical upstream's stability guarantees or avoids third-party privileged servers entirely, since the trust model is identical to Shizuku's.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Shizuku solves, in one binder
The background section of this fork's README is one of the better plain-language explanations of the underlying tool. Apps that need privileged operations traditionally shell out to su: for example, running package-manager enable and disable commands in a root shell. That approach is slow, spawning processes per command; unreliable, parsing command text; limited to whatever commands exist; and it demands root even when ADB-level permission would suffice.
Shizuku's alternative is structural. Android apps talk to system services through binder IPC; if an app holds the binder of a service, it can communicate with it, and the system server checks permissions based on the caller identity the binder carries. Shizuku guides the user to start a server process with root or ADB privileges, and when an app launches, the binder to that server is delivered to it. The server then acts as a middle man, receiving requests, forwarding them to the system server, and returning results, through a transactRemote path in the service class and a binder wrapper the README names explicitly.
To the app, using system APIs through this bridge is nearly identical to using them directly, only with the server's elevated permissions. That mechanism is what Shevery inherits unchanged, and it is the part with a decade of field testing behind it.
What the fork changes on top
The visible changes are a full Jetpack Compose manager interface with Material 3 Expressive components, motion, switches and rounded icon treatment, and build-side work targeting Android 16 and 17 with current SDK tooling, which is the practical compatibility question for a system-adjacent tool on new devices.
Two deeper additions sit in the feature list. Dhizuku support, marked experimental and placed under Laboratory features, bridges the server to a device-owner context, extending the permission story beyond root and plain ADB. And a redesigned shell-and-ADB console feature, branded Comput, adds Gemini-powered explanations, macros, and an AI command-creation flow, which pushes the tool toward assisting users who know what they want but not the exact command.
One migration warning is flagged as important and deserves equal billing: the fork changed its application signature and package identifier, and any older official Shizuku Manager must be uninstalled before installing Shevery, or the two will conflict. Fork migrations that skip that step produce support tickets, not success stories.
The ADB modules system
The largest genuine feature is a screen for installing and managing ZIP-based ADB modules, with a specification rather than a vague promise. Each module carries a module.prop manifest and banner, an enable and disable switch, an action script, a service script gated by policy, a local web interface, deletion, path checks, size limits, output limits, and last-run logs.
The policy layer is the part that shows design maturity: module execution runs under Safe mode, Full access, or a background action control setting, which acknowledges that installable automation packages are exactly the kind of thing that needs an administrator-drawn fence around it. A module catalog with direct install rounds out the distribution story, and a publishing guide documents how authors get modules into it.
Documentation is proportionate to the feature: an ADB modules guide, an API reference, a connectors API document, an Android 17 compatibility note, and the catalog publishing guide, all in the repository's docs directory.
Developer notes carried over from upstream
The developer guidance is inherited from the Shizuku ecosystem and retains its three honest caveats. ADB permissions are limited and vary across Android versions, so apps are told to check whether the server is running with ADB, and whether it holds sufficient permission, through the service's own query methods before calling APIs that may exceed ADB's grant.
Since Android 9, hidden API access is restricted for normal apps, with a well-known bypass library referenced for cases that need it. And on Android 8.0, the mechanism by which the server learns about app process starts, a combination of process and UID observers, has version-specific gaps that the README documents rather than hides.
The API itself remains the upstream Shizuku-API, with existing applications continuing to work and a migration guide for pre-v11 adopters, which means the fork buys interface and features without fragmenting the developer ecosystem it depends on.
Nine languages, weekly releases, and who ships it
The project presents itself internationally, with README translations across nine languages from English and Russian to Kazakh in both scripts, Japanese, Portuguese, Spanish, Arabic and Chinese. Releases are frequent and current: r38 on 2026-09-14, preceded by r36 on 2026-09-08 and r35 on 2026-09-07, and the last push on 2026-09-17. The licence is Apache-2.0, inherited consistently with upstream.
Notably, the user guide link still points at the upstream Shizuku site, which is simultaneously honest, since the concepts transfer, and telling, since the fork's own documentation energy went into the module system rather than basics.
The screenshots show the four surfaces: the main screen, the Comput console, the ADB modules list, and settings, which matches the feature claims one-to-one, a small thing that not every Android fork can say.
The upstream question, answered directly
The alternative to Shevery is Shizuku itself, the RikkaApps original. Upstream offers the canonical implementation, the stability reputation, the largest installed base, and first mover on Android compatibility fixes; it offers none of the module system, the modern Compose interface, the device-owner bridging or the AI-assisted console.
The fork's differentiation is real but so is its position: a signature-breaking fork means a migration step for existing users, divergence from upstream fixes over time, and a smaller team carrying Android 16 and 17 compatibility on its own cadence. Users whose entire workflow is start server, grant apps access lose nothing by staying upstream and gain simplicity. Users who want the module manager, the modern interface, or the console features are the audience, and for them the migration warning is a one-time cost.
The reviewer's judgement: the fork earns its existence on the modules system alone, which is a genuine capability upstream lacks, and everything else is polish around that decision.
Editorial conclusion
Shevery fits Android power users who already run Shizuku-style privileged tooling and want an ADB module manager with policy controls, a Material 3 interface and an AI-assisted command console, and who accept a signature-changing fork on current Android versions. It does not fit anyone who needs the canonical upstream's stability guarantees or avoids third-party privileged servers entirely, since the trust model is identical to Shizuku's. Verify first: that you have uninstalled any older Shizuku Manager as the migration requires, which policy mode your modules will run under, and whether your device's Android version is covered by the compatibility notes. The licence is Apache-2.0, and the last push was on 2026-09-17.
Frequently asked questions
What is the Shevery app?
An Android manager forked from Shizuku: it runs a server with root or ADB privileges and lets apps call higher-permission system APIs through it. The fork adds a Jetpack Compose Material 3 interface, an ADB modules system with policy gates, and an AI-assisted shell console.
Do I need to uninstall Shizuku before installing Shevery?
Yes. The fork changed its application signature and package identifier, and the README marks uninstalling any older official Shizuku Manager as a required migration step, because the two applications conflict.
Is Shevery a replacement for root?
Partly, and with limits: its server runs with either root or ADB, and ADB's permissions are limited and vary by Android version. Apps are expected to check whether the server runs with ADB and holds sufficient permission before calling privileged APIs.
Community notes