shevery is a Shizuku fork that changes your application ID and tells you to uninstall the other one

The migration notice is the first thing in the file

Before anything else there is a callout marked important, and it is about installation rather than features.

The application signature identifier changed. The upstream identifier is named in the notice, and so is the new one, and the consequence is stated as a requirement rather than a suggestion: you must uninstall any older official manager from the device first, because otherwise the two conflict.

That is a bigger deal than a version number. Android treats an application identifier as the identity of an app, so two apps sharing one identifier cannot both be installed, and two apps with different identifiers can both sit on a device competing for the same underlying service. The fork's new identifier exists so the two can coexist during testing, and the cost of that choice is that upgrading from the official manager is a migration, not an update. Any automation that references the old identifier, including scripts and other apps that bind to it, needs attention.

The upstream project is named as the reference for the fork, which is the useful thing to check when you want to know what changed.

The application identifier changed and the code namespaces did not

The fork status and the internals tell two different stories about what was renamed.

The installed identity is new, as described. But the explanation of how the tool works refers to classes under the upstream namespaces: the remote transaction method on the server class in the upstream package, and the binder wrapper class in the other upstream package.

So the application identifier moved while the code kept the upstream package names. That is the normal shape for a fork that wants existing applications and scripts to keep working against it, and the file says as much in its migration section, noting that existing applications still work.

The repository layout supports the same picture. There is a git modules file at the root, which is how a fork tracks the upstream project as a submodule rather than copying it in, so upstream changes can be pulled rather than merged by hand.

Together those three facts describe a fork that is deliberately upstream-compatible at the API surface and deliberately incompatible at the installation surface. If you are migrating, the difference between those two statements is what you need to plan around.

A module can run a script at boot, and a policy setting decides whether it does

The largest addition is a screen for installing and managing ZIP modules, and the module feature list is the most concrete part of the whole file.

A module is described by a property file, a banner, and a set of behaviours: an enable and disable switch, an action script, a service script that is policy gated, a local web interface, delete, path checks, size limits, output limits, and logs from the last run.

Two of those deserve emphasis. The service script runs without anyone tapping anything, so it is the boot time half of a module, and it is the one the file singles out as policy gated. And the path checks plus size and output limits are the guardrails: a module is a ZIP you did not write, so the app checks where it can read and write and how much it can produce.

The policy settings behind that gate are three named modes: safe mode, full access, and background action control. So the question of whether an installed module may act in the background is a setting in the manager, not a property of the module, which means the same ZIP behaves differently depending on how you have configured the app.

There is also a module catalogue with direct install, and separate documentation for the module guide, the module API and how to publish one.

The addition with the widest reach is labelled experimental

Device owner management is the feature with the widest blast radius, and it is the one the file is most careful about.

It is described as full device owner management covering app delegation scopes, ownership transfer, and device policy assisted ADB. In practice those three are: asking the user to delegate specific permissions to individual apps, transferring the device owner role between apps, and using the device policy framework as the mechanism for ADB access instead of the root shell path the tool exists to avoid.

That last one is the interesting part. The upstream problem the project exists to solve is that apps needing privileged commands shell out as root, which is slow, unreliable, and limited to whatever commands exist. Device policy delegation is the sanctioned alternative to that, which is why it is the natural place for a manager to go.

And yet the bridging system for it sits inside the features the file labels as laboratory features, described as experimental. So the capability is presented as complete and its integration path as experimental at the same time.

The file also notes the compatibility line: the work is inspired by another project and compatible with it, which is the reference to follow if you have used that one.

The problem being replaced is shelling out as root

The background section makes the argument in the form of four numbered objections to the obvious approach.

When an app needs privileged commands, the common method is to run them in a root shell. An app that wants to enable or disable a component does it by invoking the package manager command. The file's objections: it is extremely slow because of multiple process creation; it requires parsing text output, which is called super unreliable; it is limited to the commands that happen to exist; and even when ADB has sufficient permissions, the app still needs root.

The alternative is described as a binder chain. When an app asks for installed packages, it is doing interprocess communication with the system server, and Android does that with binder. Binder lets the server side learn the caller identifier and process, so the system server can check permissions on its behalf.

Each manager has a matching service in the system server, app processes are handed the binders of system services at startup, and the server learns who is calling. Shizuku's move is to have the user run one server process first, with root or with ADB, so that when an app starts, the binder to that server is sent to it as well. The app then talks to the system server through the user's server, which has the identity the user granted it.

Shevery's part is described as being a middleman: take requests from the app, forward them to the system server, return the results, so the app sees something close to a direct system API call.

The transaction code for getInstalledPackages does not exist on API 25

The developer section ends with four caveats, and the fourth is the most concrete thing in the file.

Direct use of the remote transaction method needs care, because the API is not the same on every Android version. The activity manager interface has an interface-definition language form from API 26 onward, and its stub class exists only on API 26. And the helper that looks up a transaction code can return the wrong one: the code for getting installed packages does not exist on API 25, where a suffixed variant exists instead.

The file says that particular case has been dealt with, and then immediately says it is not excluded that other circumstances may exist. That is an honest sentence, and it is also the warning: the compatibility layer is a set of known patches rather than a general guarantee.

The other three caveats set the boundaries. The ADB identity has limited permissions that differ between system versions, so the file points at the platform's own manifest for what is granted, and gives two probes to run before trusting anything: one to check whether the server is running as the user ADB identity, and one to check whether the server has sufficient permissions. Hidden API access has been restricted for ordinary apps since Android 9, with a pointer to a bypass project. And on API 26 the ADB identity lacks the permission for one of the two observers the server uses to catch app processes, so an app that might not be started by an activity is told to trigger the binder by starting a transparent activity instead.

Together those four are the reason to treat any of this as version dependent rather than universal.

Nine translated readmes, and a screenshot table with captions but no images

The file opens with a language row listing nine versions: English, Russian, Kazakh in its Cyrillic script, the same in Latin script, Portuguese, Spanish, Arabic, Simplified Chinese and Japanese. The repository root holds all nine files, so this is a translated project rather than a translated landing page.

The screenshot section is a collapsible block containing a two by two table. Each cell holds a bold caption and nothing else: a main screen, a console for the computing feature, the modules screen, and settings. No image appears in any of them, so on the repository page the section is a set of four labels.

That is the only place the interface is described visually, which means the feature list carries the whole burden of explaining what the app looks like.

Other signs of light editing are visible in the same file. The additions list includes a feature described as offering Gemini explanation alongside macros and an AI command builder, where the word for explanation is spelled with an extra syllable, and the calls to action at the end ask for a star in exchange for usefulness. None of that changes what the software does, and all of it tells you the file is written quickly by a person rather than maintained as documentation.

What the file does not do is document its own documentation: five separate documents are linked, covering the modules guide, the modules API, the connectors API, Android 17 compatibility, and how to publish a module.

Three release notes files, an undocumented Tasker directory, and strings at the root

The repository layout has a few things the file never mentions.

There are three files for release notes under three naming conventions, plus a workflow configuration for creating releases and a file that appears to hold a prepared pull request body. There is a directory for a third party automation app integration, with no mention of it anywhere in the file. There is a shell script at the root whose name suggests it activates something for testing. And there is a strings resource file sitting at the repository root rather than inside a resource directory.

The versioning scheme explains the release titles. The recent tags are a major and minor with a patch, then a fourth segment on some releases: one recent tag is a three part number, another is the same three part number with an additional revision suffix, and the newest release's title drops the patch entirely and carries a trailing space.

So a tag and its release title do not always match on the fourth segment, which is the same class of inconsistency as the identifier change in the first section: the numbers you automate against and the numbers a human reads are not always the same string.

The default branch was pushed on 2 October 2026, a day before this was assembled, and the newest release is dated 1 October. The archive flag is off, and the version numbers in the teens with a fourth revision segment say the project is past the point where a two segment version would tell you anything.

Editorial conclusion

shevery is worth installing if you want device owner delegation or boot time modules and you already run the upstream tool, because those are real additions rather than a reskin. It is a poor choice if you want a drop in replacement manager, since the application ID change means you are swapping applications rather than updating one. Three things to do first. Uninstall the official manager before installing it, or the two will conflict, exactly as the file says. Read the module policy settings before installing anyone else's ZIP, because a module can run a policy gated script at boot and the gate is a setting in the app. And if you write against the API, probe permissions at runtime rather than assuming, since the permissions the underlying shell identity has vary by Android version.

Frequently asked questions

Official sources

1. HmnDev-Tech/shevery on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases