ShizuTools: ADB-level Android control through Shizuku
Contains many tools to control android system via shizuku.
At a glance
- What is it?
- ShizuTools bundles eight Shizuku-powered tools for debloating, per-app volume, theme patching and Picture-in-Picture enforcement. Here is what each one does, how to install it, and where it stops working.
- Who is it for?
- ShizuTools suits Android users who already run Shizuku and want system-level actions without a PC, particularly debloating and per-app audio control. It is a poor fit if you expect a maintained release cadence (the newest release is v1.4.6 from 2024-10-25), if you need LookBack on a device where downgrade is blocked, or if you cannot accept the GPL-3.0 redistribution terms.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 3 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 October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What ShizuTools adds on top of Shizuku
Shizuku grants an app the ADB permission level without a cable, and ShizuTools is a collection of tools that consume that permission. The README frames the project as tools "to go beyond the level of control allowed by Android System", and the eight entries in the list map to distinct system operations rather than one general-purpose shell. Debloater removes system apps and bloatware and pulls its app information from UAD, the Universal Android Debloater Next Generation project. ThemePatcher unlocks premium content in the Oppo, Realme and Oneplus theme store. MixedAudio lets several media apps play at once or mutes specific apps. SoundMaster gives each app its own volume and can route playback to multiple audio outputs at the same time. LookBack downgrades an app without uninstalling it. UniversalPip forces Picture-in-Picture on apps that do not offer it. LocalShell runs raw ADB commands by hand, and IntentShell exposes the same capability to Tasker, MacroDroid and other automation apps through intent requests.
The audience is narrow and specific: someone who has already set up Shizuku, knows what an ADB command is, and wants a graphical front end for actions that would otherwise need a desktop and a USB cable. If that description does not match you, the app will look like a set of switches with no explanation attached.
How the Shizuku permission is turned into system actions
The repository is a single-module Gradle Android project: app/ holds the Kotlin sources, with build.gradle and settings.gradle at the top level and a gradle wrapper checked in. There is no server component and no companion daemon in the tree. The app talks to the Shizuku service that the user has already started, and each tool issues the ADB-level calls it needs through that channel. That is why the README routes you to Shizuku first and to the APK second.
The two shell tools are the clearest illustration of the data flow. LocalShell takes a raw ADB command from the user and executes it under the granted permission. IntentShell accepts an intent from an external automation app and runs the ADB command carried in that request. Everything else in the list is a purpose-built wrapper around the same channel: Debloater issues uninstall calls against the package list it reads from UAD, SoundMaster and MixedAudio manipulate audio focus and per-app streams, UniversalPip forces the PiP state on an activity, and LookBack reinstalls a lower version over the existing one.
One design consequence is worth stating plainly. Because ShizuTools is a client of Shizuku rather than a root tool, it inherits Shizuku's limits: if the Shizuku service is not running, every tool in the app is inert. The README does not describe a fallback path.
Installing ShizuTools and running a first ADB command
The README gives two install routes and no build instructions. The stable APK comes from the latest GitHub release, which at the time of writing is v1.4.6. The development build is committed directly to the repository at app/release/app-release.apk on the master branch. Both are sideloaded APKs, so you need to allow installation from your file manager or browser first.
Start Shizuku before opening ShizuTools. The app depends on that service for every operation, so a first launch without it will show tools that cannot act.
The lowest-risk way to confirm the permission chain works is LocalShell, because it does not modify anything. Open the LocalShell tool and run a raw ADB command. The README describes LocalShell as the place to "manually execute other raw ADB commands", but it does not print an example command, so use a read-only one from your own knowledge and check that output comes back.
If Shizuku is running and ShizuTools holds the permission, the command returns output. If nothing appears, the problem is the Shizuku connection, not the command.
For automation, IntentShell is the entry point the README points at for Tasker and MacroDroid. The wiki page linked from the README is where the intent format lives; the README itself does not spell out the extras or the action string, so read that page before wiring anything up.
Where ShizuTools fails or is the wrong tool
LookBack is the clearest limitation, and the README states it directly: it "does not work on all devices". Downgrade without uninstallation depends on version-code behaviour that Android has tightened over successive releases, and the project offers no compatibility list. Treat LookBack as something to test on your own hardware before relying on it.
The release history is the second constraint. The most recent release is v1.4.6, published on 2024-10-25, and the two before it are v1.4.4 from 2024-09-29 and v1.4.3 from 2024-06-27. The repository's last push was on 2026-07-28, so work has continued in the tree since the last tagged release, but anyone installing the stable APK is running a build from October 2024. The README's own note sets expectations: the author asks for suggestions and bug reports but warns that responses will not be swift.
Third, the scope is deliberately partial. UniversalPip forces PiP onto apps that refuse it, and the README itself names a better alternative for that job, Extendroid, in a line directly beneath the tool list. If PiP is the only thing you want, ShizuTools is not the project to start with.
Finally, the permission model is all-or-nothing in practice. LocalShell and IntentShell execute raw ADB commands. Anything you can do through them is your responsibility, and the README does not document a confirmation step or an audit log.
ShizuTools compared with Universal Android Debloater
The Debloater tool inside ShizuTools uses app information from UAD, the Universal Android Debloater Next Generation project, so the two are related rather than unrelated. The difference is where the ADB session lives. UAD runs on a desktop and talks to the phone over a USB or wireless ADB connection, which means you need a computer, a cable or a pairing session, and platform-tools installed. ShizuTools runs the same class of uninstall operation on the phone itself, using Shizuku as the permission source.
That trade is real in both directions. On-device operation removes the PC from the workflow, which matters if you are cleaning up a phone you do not own a cable for. The desktop approach keeps the command surface on a larger screen with a keyboard, and it does not require Shizuku to be installed and running on the device. If you already have a workstation set up and you debloat rarely, UAD is the simpler dependency chain. If you want to remove a system app while away from a computer, ShizuTools is the one that works.
Licence terms and what upgrading costs you
ShizuTools is licensed under GNU General Public License v3.0. The README adds two conditions beyond the licence text: you must not distribute the software, original or modified, to any platform without its source code or a reference to the original source code, and publishing to any app store without permission is forbidden. Those are the project's stated terms, not legal advice; if you plan to redistribute a fork, read the LICENSE file and the README note together and decide for yourself.
Upgrade cost is mostly a matter of which build you track. The stable path means watching GitHub releases, and the gap between v1.4.6 in October 2024 and the last push on 2026-07-28 suggests the tree moves ahead of the tags. The development path means pulling app/release/app-release.apk from master, which is a moving target. There is no Play Store channel and no auto-update mechanism described in the README, so either way you are checking the repository yourself. Building from source is possible in principle given the Gradle wrapper and app module, but the README documents no build steps, so that route is undocumented.
Editorial conclusion
ShizuTools suits Android users who already run Shizuku and want system-level actions without a PC, particularly debloating and per-app audio control. It is a poor fit if you expect a maintained release cadence (the newest release is v1.4.6 from 2024-10-25), if you need LookBack on a device where downgrade is blocked, or if you cannot accept the GPL-3.0 redistribution terms. Before installing, verify that Shizuku starts on your Android version, check whether your device appears in the LookBack caveats, and read the wiki pages for SoundMaster, UniversalPip and IntentShell, since the README does not document their flags or rollback behaviour.
Frequently asked questions
How do I install ShizuTools?
Install the latest release APK from the project's GitHub releases page, or the development build committed at app/release/app-release.apk on the master branch. Shizuku must be running on the device for the tools to work.
How do I use ShizuTools?
Start Shizuku first, then open the app and pick a tool from the list: Debloater, ThemePatcher, MixedAudio, SoundMaster, LookBack, UniversalPip, LocalShell or IntentShell. SoundMaster, UniversalPip and IntentShell each have a wiki page linked from the README that the README itself does not reproduce.
Does ShizuTools work without Shizuku?
The README presents ShizuTools as a set of tools that operate through Shizuku, and it lists no alternative permission path. Without the Shizuku service running, the tools have no channel to issue their ADB-level calls.
Can ShizuTools downgrade any app?
No. The README states that LookBack, the downgrade tool, does not work on all devices, and it does not provide a compatibility list.
Is there a better option than ShizuTools for Picture-in-Picture?
The README names Extendroid as a better alternative to UniversalPip, the tool that forces Picture-in-Picture mode. If PiP is your only goal, start there.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/legendsayantan-shizutools)