Wireless debugging, Shizuku, and the display app are separate layers
Wireless debugging is Android's transport and authorization layer. Shizuku is a service started with ADB-level or root identity. A display app is the client that asks Shizuku for a per-app grant. Pairing wireless debugging does not start Shizuku, and starting Shizuku does not automatically approve every app.
This separation is a feature. It lets you revoke one app without forgetting the phone's wireless-debugging pairing, and it keeps a normal app from silently becoming privileged.
| Layer | Its job | What it does not prove |
|---|---|---|
| Wireless debugging | Authorizes an ADB connection on Android 11+ | That Shizuku is running |
| Shizuku service | Exposes selected system API access through shell/root identity | That a client app is trusted |
| Per-app grant | Allows one chosen app to call Shizuku | That every requested operation is supported |
Before pairing
- Install Shizuku only from its official site, Google Play, or the project's signed GitHub releases.
- Use a network you trust. Wireless debugging exposes a powerful developer surface while enabled.
- Record the original display values before opening an advanced changer.
- If the phone is managed by work or school, do not bypass administrator restrictions.
- Know where Android stores Revoke USB debugging authorizations so you can clean up later.
Pair once, start after boot, grant one app
- 1.Enable Developer options using the manufacturer-supported Build number flow.
- 2.Enable USB debugging and Wireless debugging. Android may ask whether to trust the current network.
- 3.Open Shizuku, choose Start via wireless debugging, and begin pairing.
- 4.In Android's Wireless debugging screen, choose Pair device with pairing code and enter that code through Shizuku's prompt.
- 5.Return to Shizuku and tap Start. Confirm that Shizuku reports the service as running.
- 6.Open the display app and approve its Shizuku request only after confirming the developer and purpose.
What survives a reboot
On non-root devices, the service normally stops when the phone reboots. The pairing relationship commonly remains, so the usual post-reboot action is to re-enable wireless debugging if needed, open Shizuku, and start the service again.
An app may retain its grant but still report Shizuku as unavailable until the service starts. That is different from a revoked permission. Diagnose the service state first.
| State | Usually after reboot | Action |
|---|---|---|
| Wireless pairing | Often retained | Re-pair only if Android forgot or revoked it |
| Shizuku service | Stopped on non-root setup | Start it again |
| Client app grant | Often retained | Review only if denied or revoked |
Troubleshoot by symptom, not by random toggles
| Symptom | Check first | Then |
|---|---|---|
| Pairing notification never appears | Notification permission and Wireless debugging state | Restart the documented pairing flow |
| Searching for pairing service | Same trusted Wi-Fi, no local-network isolation, wireless debugging enabled | Toggle wireless debugging as the official guide suggests |
| Shizuku runs but the app cannot connect | The app's Shizuku grant | Restart the client app and review its compatibility |
| It worked yesterday but not after reboot | Shizuku service status | Start the service again; do not reinstall |
| Display command is denied | Whether ADB shell has that permission on this build | Use another documented route; Shizuku cannot manufacture missing privileges |
Clean up access you no longer need
- Turn off Wireless debugging after Shizuku has started if the current official workflow and your device allow it.
- Remove Shizuku permission from client apps you no longer use.
- Use Revoke USB debugging authorizations if you paired with a computer you no longer trust.
- Uninstall unofficial helper APKs rather than granting them broader access.
- Do not share pairing codes, debugging screenshots containing identifiers, or support logs with tokens and account data.
When another route is better
A one-time computer ADB grant can be simpler for someone who already trusts a computer and wants the app to work without restarting Shizuku after every boot. Root may be appropriate only for users who already maintain a rooted device and understand that larger trust boundary. Built-in Display size remains the right route for ordinary readability changes.
The best setup is the least privileged one that reliably completes the job.
Questions, answered
Frequently asked questions
Does Shizuku root my phone?+
No. A non-root Shizuku session normally uses Android's ADB shell identity. Root startup is a separate option on an already-rooted device.
Why does Shizuku stop after reboot?+
The non-root service is started through ADB and is not a persistent system service. Restarting it after boot is expected behavior documented by the project.
Is Shizuku safe?+
Shizuku narrows access through per-app grants, but approved clients receive powerful capabilities. Install it from official sources and approve only apps whose developer and purpose you trust.
Sources and review notes
We favor platform documentation and original project material. Device-maker behavior can still differ, so manufacturer-specific claims are kept narrow.
- Shizuku user manual: setup
Shizuku — Official pairing, startup, reboot, and troubleshooting instructions.
- Shizuku API developer guide
RikkaApps on GitHub — Explains the shell/root identity model and restart requirements for non-root devices.
- Shizuku releases
RikkaApps on GitHub — Signed release history and current compatibility notes.
- Run apps on a hardware device
Android Developers — Documents wireless debugging and pairing on Android 11 and later.
- Configure on-device developer options
Android Developers — Official overview of Developer options and debugging controls.