What Users Need to Set Up Before Using Shizuku
Updated
Shizuku lets apps call privileged system APIs without root, but it is not a standalone tool that works the moment you install it. Before any app can use it, you need three things in place: the Shizuku app itself, a running Shizuku service started through adb, and apps that are built to request Shizuku access. If the service is not running, Shizuku-dependent features in those apps will simply be unavailable.
Install the Shizuku App
The first step is installing Shizuku on the device. This is the app that manages the privileged connection and exposes it to other apps.
- Install Shizuku from its official distribution source.
- No root is required for the standard setup path.
- The app is the bridge: other apps talk to system APIs through it rather than through a root shell.
Start the Shizuku Service via ADB
Installing the app is not enough. The Shizuku service has to be started, and the documented path is through adb.
The site describes this as "Supports adb usage" — if an app only needs adb-level permission, Shizuku is the way to grant it without root. Practically, that means:
- Enable developer options and USB debugging on the device.
- Connect the device to a computer with adb available.
- Use adb to start the Shizuku service.
- Keep the service running for apps to use it.
The key point is that the service is a running process, not a permanent install-time switch. If it stops, apps lose access until it is started again.
Apps Must Request Access
Shizuku does not automatically grant every app elevated privileges. An app has to be written to use Shizuku and to request permission through it.
The site's example shows what this looks like from the developer side — wrapping a system service and calling a privileged method:
private static final IPackageManager PACKAGE_MANAGER =
IPackageManager.Stub.asInterface(
new ShizukuBinderWrapper(
SystemServiceHelper.getSystemService("package")));
public static void grantRuntimePermission(String packageName,
String permissionName,
int userId) {
try {
PACKAGE_MANAGER.grantRuntimePermission(packageName, permissionName, userId);
} catch (RemoteException tr) {
throw new RuntimeException(tr.getMessage(), tr);
}
}
For a user, the takeaway is simpler: the app you want to use must support Shizuku. If it does not, installing Shizuku will not add the feature.
Check That Shizuku Is Running
Because access depends on a live service, the running state matters. The site notes there are "a few more steps to do, like checking permission or if Shizuku is running" — that check exists precisely because the service can be inactive.
Before expecting a feature to work:
- Confirm the Shizuku service is active.
- Confirm the specific app has been granted Shizuku permission.
- If either is missing, the privileged call will fail or the feature will be hidden.
What This Means in Practice
| Requirement | Why it matters |
|---|---|
| Shizuku app installed | Provides the bridge to system APIs |
| Service started via adb | Privileged access only exists while the service runs |
| App supports Shizuku | Unsupported apps gain nothing from Shizuku |
| Permission granted + service running | Both conditions must hold for features to work |
Shizuku is faster than a shell-based approach and removes the need for root, but it trades that convenience for a setup step: you start the service through adb, and you keep it running. Once those conditions are met, supported apps can use system APIs directly.