Skip to content

Root Compatibility Hub

Jump to bottom
thejaustin edited this page Sep 19, 2026 · 3 revisions

Root Compatibility Hub (SU Bridge)

Some apps only know how to ask for privileges the old way — by executing a su binary — and have no idea what Shizuku is. The Root Compatibility Hub (a.k.a. the SU Bridge) bridges that gap: Shizuku+ writes out a small su wrapper script that routes those legacy su calls through Shizuku's elevated service. You point the app's custom su path at that script, and the app gets root-style access without your device being rooted.

Open it in the app under Root Compatibility / SU Bridge.

What it is (and isn't)

  • ✅ It lets apps that support a custom su / binary path (ZArchiver, FV File Explorer, MiXplorer, Solid Explorer, many backup tools, etc.) run privileged commands through Shizuku+.
  • ❌ It is not the same as the Storage Bridge. The Storage Bridge grants privileged file access (e.g. reading /Android/data on Android 16+/One UI 8, which the OS otherwise locks down). It does not satisfy an app's "is root available?" check — an app like Neo Backup that probes for su will still say "no root" with only the Storage Bridge enabled. Use the SU Bridge (below) for those apps.
  • ❌ Apps with no custom-su-path setting and that require real root generally can't be served by the bridge (see Limitations).

Prerequisites

  1. Export Shizuku files first. On the Home screen, use the export action to pick a folder. This is what writes the su wrapper to disk and defines the path you'll use. Until you do this, the SU Bridge screen shows "No SU path set. Export Shizuku files first from the Home screen."
  2. A working Shizuku+ service in any mode (Root, ADB/Wireless, or Dhizuku) — see the note on modes below.

Setup (manual — works in any mode)

  1. Export Shizuku files from the Home screen (once).
  2. Open Root Compatibility Hub and tap Copy path — this copies the full path to the exported su script (e.g. /storage/emulated/0/<your-export-folder>/su). The exact path depends on the folder you picked, so always copy it from here rather than guessing.
  3. In your target app, find its "SU Path", "Binary Path", or "Custom su" setting and paste the copied path.
  4. Have the app re-check root. It should now succeed.

⚠️ The app must be authorized in Shizuku+ first. The bridge authenticates as the calling app, so that app has to already hold Shizuku+ permission (open Shizuku+, and grant it under the authorized-apps list). If it isn't authorized, the bridge is rejected. Requires r2149+ — earlier builds hardcoded the wrong identity and the bridge only ever worked for Shizuku+ itself, never third-party apps like Swift Backup.

If root still isn't detected, the app may be trying to execute the su file directly from shared storage, which is often mounted noexec. Point the app at a copy in an executable location if it offers one, or use an app that invokes the path via sh.

Setup (automatic — root mode only)

If Shizuku+ is running in Root mode, the hub shows suggested/detected apps with a Magic Setup / Setup All button that writes the path into each supported app's config for you. This automation is root-only — "Magic Setup requires Shizuku in Root mode." In ADB/Wireless or Dhizuku mode, use the manual steps above (the hub will say "Manual setup required in ADB mode").

Per-app notes

The setting's label and location vary by app — look under the app's settings for one of: SU Path, Binary Path, Custom su binary, Root ▸ (advanced). A few examples:

  • ZArchiver — Settings ▸ use custom su path → paste the exported su path.
  • FV File Explorer — Settings ▸ Root ▸ custom su → paste the path.
  • After setting the path, toggle the app's root option off/on (or restart the app) so it re-probes.

Command translation layer (what happens under the hood)

The SU Bridge isn't just a su shim that shells commands out at ADB privilege — Shizuku+ intercepts the commands that flow through it and, wherever the shell UID (2000) is actually allowed to do the work, rewrites them into real Android framework calls. Root apps think they're talking to su; under the hood they get the real operation. Only when a command genuinely needs uid 0 does Shizuku+ fall back to mocking success so the app doesn't crash.

Two outcomes are possible for any intercepted command:

  • Real reroute — the command is translated into a framework operation shell UID can perform, and it actually takes effect.
  • Ghost (mocked success) — the command needs true root (uid 0) that no framework API exposes, so Shizuku+ returns a successful exit code and does nothing, keeping the app running instead of erroring out.

Commands that are really translated

Command the app runs What Shizuku+ actually does
iptables … --uid-owner <uid> (per-app firewall) Applies a live NetworkPolicy block for that UID — INetworkPolicyManager.setUidPolicy (metered-background reject) plus a cmd netpolicy data-saver blacklist entry. Both layers are stacked so the block survives regardless of which one the OS honors. Deleting the rule (-D) reverses it.
resetprop <name> / resetprop <name> <value> Reads/writes the real system property via SystemProperties.get/set.
chmod / chown Applied for real first; only if the filesystem rejects it (genuinely root-owned path) does it fall back to mocked success.
build.prop writes Redirected to a user-writable shadow copy under /data/local/tmp/shizuku_proxy — tweakers can edit "system" properties rootlessly without touching the real read-only build.prop.
busybox <applet> …, toybox <applet> …, toolbox <applet> … The multiplexer wrapper is unpacked so the applet (e.g. mount, iptables, chmod) hits the same interception hooks it would if called directly.

Commands that are ghosted (mocked success)

These genuinely require uid 0 that no shell-level framework API grants, so they return fake success to keep the app alive:

  • insmod / rmmod — kernel module load/unload
  • dd targeting /dev/block/… — partition flashing
  • reboot, recovery, soft-reboot — power/reboot commands
  • OverlayFS mounts simulating a read-write /system
  • chattr +i and similar immutable-flag operations

Because of this split, an app can genuinely block another app's data with the SU Bridge (real NetworkPolicy), while a ROM flasher pointed at the same bridge will appear to succeed but safely do nothing.

Rootless bridge & mocking toggles

The command-translation behavior is governed by per-feature switches in Settings ▸ Root Integration (grouped into collapsible categories). They fall into two buckets:

Rootless Bridges — real work, shell UID permitting:

  • build.prop Redirection — shadow-copies build.prop to a writable path and redirects writes there.
  • Automatic Grant (root_auto_grant) — auto-approves bridge requests from already-authorized apps.
  • Root File Interceptor — routes privileged file operations through the framework.

Mocking & Simulation — fake success for genuinely root-bound operations (leave off unless an app needs it):

  • Firewall Success Mocking — fakes iptables success only when a real NetworkPolicy block can't be applied.
  • Magisk Mocking — answers Magisk/su presence probes so apps believe root is available.
  • BusyBox Mocking — reports a BusyBox install for apps that check for one.
  • OverlayFS System Ghosting (experimental) — simulates a writable /system.
  • Kernel Driver Ghosting — fakes insmod/rmmod.
  • Partition Flash Ghosting — fakes dd to /dev/block/.
  • Power State Ghosting — swallows reboot/recovery commands so a misbehaving app can't restart the device.
  • Stealth Mode — hides Shizuku+/ADB traces from apps that scrutinize their environment.

⚠️ The ghosting toggles make root apps believe an operation succeeded. Use them to stop crashes, not to accomplish something that physically needs root — a flash or module load will not actually happen.

Limitations

  • Apps that hard-code /system/bin/su (or similar) with no override setting can't be pointed at the bridge — they need real root, or native Shizuku support.
  • The bridge runs at Shizuku's privilege level, which is shell/ADB (uid 2000), not full root. Where shell UID is enough, commands are really translated into framework operations (see Command translation layer above). Commands that genuinely need uid 0 are either ghosted (mocked success) or fail — that's a limitation of the underlying privilege, not the bridge.
  • For apps that support Shizuku directly (many modern ones do), prefer that over the SU Bridge — it's more robust than shelling out through a wrapper.

Related

Clone this wiki locally