Repository navigation
Permissions
Shizuku+ requests more permissions than stock Shizuku because it does more than stock Shizuku — every entry below maps to a real feature, and every feature can be turned off in Settings → Plus Features if you'd rather not use it (and thus don't need the permission it depends on).
This page exists because we think "grant this permission" shouldn't ever be a leap of faith. If you find a permission here that seems undocumented, open an issue — that's a bug in this page, not something to just accept.
Powers the persistent "Shizuku+ is running" status notification, Watchdog crash alerts, and update-progress notifications. Declining this doesn't stop the service — you just won't see status/crash notifications. See Service Connection & Start Flow.
Required by Android for the mDNS scan that discovers the Wireless Debugging port automatically, so you don't have to manually type an IP/port. Declared neverForLocation — Shizuku+ never reads your physical location through this permission, only local network service discovery.
Android 16+ gates all loopback (127.0.0.1) traffic and local mDNS discovery behind these. Without them, wireless-debugging discovery and the ADB pairing/connect handshake can't reach the device at all — this isn't optional plumbing on newer Android, the connection simply doesn't work without it.
Only requests the system dialog that lets you exempt Shizuku+ from Doze/App Standby killing the background service. You choose whether to grant it; declining just means the service is more likely to get killed in the background (mitigated by Watchdog).
Needed for the in-app updater to install a downloaded APK directly, and for the Compat Hub companion-app installer, without bouncing you out to a separate installer flow each time.
New. Powers the external Watchdog re-arm described in Service Connection & Start Flow § Watchdog — a scheduled alarm that can restart the service even if Samsung's "Sleeping apps" freezer (or a similar OEM battery killer) has frozen the entire app process, since the alarm is dispatched by the system, not by anything running inside our own process. This is best-effort: it's a runtime-revocable permission, and if you decline it (or your OEM restricts it), Shizuku+ automatically falls back to an inexact wake instead of failing outright.
These don't show a permission dialog — Android grants them at install time because they're "normal" protection-level, but we still think you should know they exist and why.
| Permission | Why |
|---|---|
RECEIVE_BOOT_COMPLETED |
Restarts the service and Watchdog after a reboot, if you enabled Start on boot. |
FOREGROUND_SERVICE, FOREGROUND_SERVICE_SPECIAL_USE, FOREGROUND_SERVICE_CONNECTED_DEVICE, FOREGROUND_SERVICE_DATA_SYNC
|
Android 14+ requires every foreground service to declare which kind of foreground work it's doing. These cover the Watchdog service, the ADB pairing service, and background sync work respectively. |
INTERNET, ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_WIFI_MULTICAST_STATE
|
Update checking (GitHub Releases), and the mDNS/multicast socket work behind Wireless Debugging discovery. Shizuku+ does not send your data anywhere beyond GitHub's release API and your own device's local network — see Shizuku vs. Shizuku+ for the full architecture. |
QUERY_ALL_PACKAGES |
Needed to list installed apps for the Activity Log, App Management, and permission-granting screens — without it we could only see apps that explicitly declare an intent-filter matching ours. |
DOWNLOAD_WITHOUT_NOTIFICATION |
Lets the in-app updater manage its own progress notification instead of DownloadManager's default one. |
These are not requested from you — they're requested by Shizuku+ from itself, through the privileged process it starts via ADB, root, or Dhizuku Mode. This is the actual point of Shizuku: giving normal apps access to APIs that would otherwise require root.
The core privileged permission the whole project exists to provide. Once the privileged process is running, apps you authorize (via the consent prompt — see Service Connection) can use it through Shizuku+'s API for things like changing system settings, managing app permissions, and more — always mediated by your per-app authorization, never silently.
Backs the Root Compatibility Hub's app-usage-aware features (like flagging apps that haven't been granted root/Shizuku access recently) and some Deep Process Control features. Declared tools:ignore="ProtectedPermissions" because it's a protected permission the manifest can't self-grant — it only becomes usable once Shizuku+'s privileged process grants it via appops/pm grant, the same way it would for any Shizuku-aware app.
The private channel between the Shizuku+ manager app and its own privileged server process. Signature-level means only an app signed with the same key (i.e., Shizuku+ itself) can use it — no other app can pretend to be the manager. Scoped per-applicationId (Plus vs. Drop-In builds) so both flavors can be installed side by side without permission-group collisions (#316).
Compatibility permission so apps built against the original Shizuku API (which predates the af.shizuku.plus namespace) can talk to Shizuku+ transparently. This is what makes "100% compatible with existing Shizuku-enabled apps" (see the Home page) actually true rather than aspirational.
If you're comparing manifests: no ACCESS_FINE_LOCATION/ACCESS_COARSE_LOCATION (the Wi-Fi/nearby-devices permissions above are explicitly neverForLocation), no READ_CONTACTS/READ_SMS/READ_CALL_LOG or other personal-data permissions, no advertising ID, no analytics SDK beyond crash reporting (Sentry — see Knowledgebase for what that does and doesn't send). If a future feature needs something in that territory, it'll be documented here before it ships, not after.