Shizuku: Android-Apps mit ADB-Rechten, ohne Root

Shizuku

ADB-Rechte für Apps.

Foto: Silberfuchs / Pixabay

Eine App, ein Dienst und fünf Schritte: Dann dürfen ausgewählte Apps Systemfunktionen nutzen, für die sonst Root nötig wäre. Dieser Artikel erklärt, wie Shizuku das macht und worauf du achtest.

Der Artikel ist Teil 3 der Reihe „Android-Tablet per ADB“. Teil 1 behandelt den Nova Launcher, Teil 2 die Automatisierung mit MacroDroid.

Das Wichtigste in Kürze

• Shizuku braucht kein Root. Die App startet einen Prozess mit den Rechten der ADB-Shell und gibt sie an Apps weiter, die du freischaltest.
• Nach jedem Neustart startest du den Dienst neu. Das Handbuch nennt Systembeschränkungen als Grund, nur mit Root entfällt der Schritt.
• Unter Android 11 und höher startest du ohne Computer. Wireless Debugging und ein einmaliges Koppeln genügen.
• Jede freigeschaltete App erhält die Rechte der ADB-Shell. Gib sie deshalb nur Apps, deren Hersteller du kennst.
• Die Prüfung gelingt per ADB. Ein Skript zeigt, ob der Dienst läuft und welche App ihn nutzen darf.

Was Shizuku ist

Android trennt Apps vom System. Deshalb darf eine normale App darf viele Systemfunktionen nicht aufrufen, etwa Komponenten anderer Apps abschalten. Dafür braucht sie Rechte, die nur die ADB-Shell oder Root besitzen. Shizuku schliesst die Lücke. Laut der Einführung lässt die App einen Java-Prozess mit ADB- oder Root-Rechten laufen, über den Apps Systemschnittstellen direkt ansprechen.

Dabei steht der Entwickler Rikka hinter dem Projekt. Der Quelltext liegt unter github.com/RikkaApps/Shizuku und steht unter der Apache-2.0-Lizenz. Die letzte veröffentlichte Version ist laut GitHub 13.6.0 vom 25. Mai 2025 (abgerufen am 24. Oktober 2026). Im Play Store trägt sie das Paket moe.shizuku.privileged.api, die dortige Beschreibung nennt sie eine quelloffene App, die mehrere Apps mit Root- oder ADB-Bedarf bedient.

Zudem vergleicht das Handbuch Shizuku mit dem alten Weg. Früher rief eine Root-App für jeden Befehl ein neues Programm auf, etwa pm disable, und las den Text der Antwort aus. Das war langsam und fehleranfällig. Bei Shizuku sendet der Dienst der App ein Binder-Objekt, und sie spricht die Systemdienste fast so an wie ein Systemprogramm.

Wie der Dienst startet

Das Benutzerhandbuch nennt drei Wege.

Wireless Debugging. In den Entwickleroptionen schaltest du USB-Debugging und Wireless Debugging ein. In Shizuku startest du die Kopplung, tippst im System auf „Pair device with pairing code“ und gibst den Code in der Benachrichtigung von Shizuku ein. Danach startet ein Tipp den Dienst. Hilft das nicht, schaltest du Wireless Debugging aus und wieder ein. Zeigt Shizuku dauernd „Searching for pairing service“, muss die App im Hintergrund laufen dürfen, denn die Suche braucht Zugriff auf das lokale Netz.

Computer mit ADB. Das Handbuch führt diesen Weg für Android 10 und älter. Der Befehl lautet laut Handbuch ab Shizuku 11.2.0:

adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

Auf neueren Geräten bleibt der Weg über Wireless Debugging der vorgesehene. Auf meinem Tablet mit Shizuku 13.6.0 und Android 16 gab es diese Datei allerdings nicht, der Befehl lief ins Leere. Funktioniert hat der Start über die Bibliothek, die im Paket der App mitgeliefert wird:

p=$(adb shell pm path moe.shizuku.privileged.api | sed 's/package://;s#/base.apk##')
adb shell $p/lib/arm64/libshizuku.so

Die erste Zeile ermittelt den Installationsordner der App, die zweite bringt den Dienst hoch.

Warum der Dienst nach dem Neustart fehlt

Shizuku ist kein Systemdienst. Ein Prozess mit den Rechten der ADB-Shell läuft nur, solange das Gerät an ist. Nach einem Neustart ist er verschwunden, und die Kopplung per Wireless Debugging steht erst wieder bereit, wenn das Gerät im WLAN ist. Das Handbuch sagt knapp, wegen Systembeschränkungen müssten die Startschritte nach jedem Neustart erneut ausgeführt werden. Nur mit Root startet der Dienst von allein.

Dazu nennt das Handbuch bei Geräten, auf denen Shizuku „zufällig“ stoppt, Gegenmittel. Shizuku braucht Erlaubnis zum Hintergrundbetrieb, USB-Debugging und Entwickleroptionen bleiben an, und ab Android 11 hilft die Option „Disable adb authorization timeout“. Hersteller wie Xiaomi, Oppo und Huawei haben eigene Schalter, die das Handbuch einzeln aufführt.

Für ein Kiosk-Tablet heisst das: Nach einem Stromausfall startet der Dienst nicht von selbst. Planst du Makros, die Shizuku brauchen, hilft eine Warnung. MacroDroid bietet dafür den Auslöser Shizuku Stopped. Die Wiki-Seite rät, den Dienst danach per ADB oder Wireless Debugging neu zu starten.

Welche Apps Shizuku nutzen

Eine App kann Shizuku nur nutzen, wenn ihr Entwickler die Schnittstelle einbaut. Die Shizuku-API beschreibt, wie. Die App fragt das Recht ähnlich ab wie ein Laufzeitrecht und bekommt eine Zustimmung oder Ablehnung.

Als Beispiel taucht MacroDroid in seiner eigenen Hilfe auf. Die Wiki nennt drei Stellen, an denen es Shizuku verwendet:

• Die Aktion Shell Script kennt neben „Rooted“ die Option „Shizuku“ und führt den Befehl dann mit erhöhten Rechten aus.
• Die Aktion Screen On/Off bietet „Screen Off - No Lock (root or Shizuku)“.
• Der Dialog für die ADB-Rechte zeigt „Grant with Shizuku“, wie die Seite ADB Hack erklärt.

Andere Apps habe ich nicht geprüft. Wer eine App mit Shizuku-Unterstützung sucht, liest deren Beschreibung. Ein Verzeichnis aller Apps liefert die Dokumentation nicht.

Sicherheit: Wem du Zugriff gibst

Shizuku vergibt keine Rechte, die ADB nicht ohnehin hat. Die Entwickler-Hinweise betonen, dass ADB nur eingeschränkte Rechte besitzt, die sich zwischen Android-Versionen unterscheiden. Welche, zeigt das Manifest der Shell im Android-Quelltext. Dort stehen unter anderem WRITE_SECURE_SETTINGS, READ_LOGS, DUMP und CHANGE_CONFIGURATION, dieselben Rechte, die MacroDroid per pm grant erhält.

Damit bekommt eine App mit Shizuku-Zugriff trotzdem viel Macht. Sie kann, was die ADB-Shell kann, ohne dass du jedes Mal etwas bestätigst. Drei Regeln halten das Risiko klein:

1. Gib den Zugriff nur Apps, deren Entwickler und Quelle du kennst.
2. Prüfe nach, welche Apps das Recht halten (Befehl weiter unten).
3. Lass den Dienst nur laufen, solange du ihn brauchst. Ein Neustart stoppt ihn, und die Apps verlieren den Zugriff.

Ein Tablet im Kiosk, das nur dir gehört, hat ein kleines Risiko. Auf einem Gerät mit fremden Nutzern oder vielen Apps aus unklaren Quellen lohnt sich der Dienst selten.

Prüfen per ADB

So siehst du von aussen, ob Shizuku läuft und wer es nutzen darf. Alle Befehle lesen nur.

adb shell pm list packages moe.shizuku.privileged.api
adb shell dumpsys package moe.shizuku.privileged.api | grep versionName
adb shell "ps -A | grep -i shizuku"
adb shell dumpsys package <paket> | grep "API_V23"

Die erste Zeile zeigt, ob die App installiert ist, die zweite ihre Version. Die dritte listet laufende Prozesse mit „shizuku“ im Namen, eine leere Ausgabe heisst: Der Dienst läuft nicht. Die vierte zeigt für eine App, ob sie das Recht moe.shizuku.manager.permission.API_V23 besitzt. Der Name des Rechts stammt aus dem Paket von MacroDroid auf meinem Gerät, die Dokumentation nennt ihn nicht ausdrücklich.

Das folgende Skript fasst die Prüfung zusammen. Ohne die Umgebungsvariable START=1 ändert es nichts am Gerät. Mit START=1 versucht es zuerst start.sh und nimmt sonst libshizuku.so.

#!/usr/bin/env bash
set -euo pipefail
GERAET="${1:?Aufruf: shizuku-pruefen.sh <ip:port> [paket ...]}"
shift
SZ=moe.shizuku.privileged.api
A() { adb -s "$GERAET" "$@"; }

A get-state | grep -q device || { echo "Gerät nicht erreichbar" >&2; exit 1; }
if ! A shell pm list packages "$SZ" | grep -q "$SZ"; then
  echo "Shizuku ist nicht installiert."; exit 0
fi
A shell dumpsys package "$SZ" | grep -m1 versionName
if A shell "ps -A | grep -i shizuku" | grep -q .; then
  echo "Dienst läuft."
else
  echo "Dienst läuft nicht: in der Shizuku-App per Wireless Debugging starten, oder mit START=1 per ADB."
  if [ "${START:-0}" = 1 ]; then
    SD=/sdcard/Android/data/$SZ/start.sh
    if A shell "test -f $SD"; then
      A shell "sh $SD"
    else
      P=$(A shell pm path "$SZ" | head -1 | tr -d '\r' | sed 's/package://;s#/base.apk##')
      A shell "$P/lib/arm64/libshizuku.so"
    fi
  fi
fi
for P in "$@"; do
  if A shell dumpsys package "$P" | grep -q "API_V23: granted=true"; then
    echo "$P: Zugriff erteilt"
  else
    echo "$P: kein Zugriff"
  fi
done

Dabei kann ein KI-Agent das Skript gefahrlos ausführen, weil es nur liest. Zum Starten per Wireless Debugging braucht er einen Menschen, denn die Kopplung verlangt den Code vom Bildschirm. Besteht bereits eine ADB-Verbindung, geht es mit libshizuku.so ohne diese Kopplung.

Meine Erfahrung

Auf meinem Galaxy Tab A11 (SM-X230, Android 16) ist Shizuku in Version 13.6.0 installiert. Die App wurde am 5. Oktober 2026 ohne Store-Kennung installiert, vermutlich per ADB. Zuerst habe ich am 24. Oktober 2026 nur gelesen, und ein laufender Shizuku-Prozess war nicht zu sehen. Die Datei start.sh unter /sdcard/Android/data/moe.shizuku.privileged.api/ existierte auf diesem Gerät nicht.

Am selben Tag habe ich den Dienst über die mitgelieferte Bibliothek hochgefahren, mit den zwei Zeilen aus dem Abschnitt „Wie der Dienst startet“. Die Ausgabe endete mit „shizuku_starter exit with 0“. Danach lief der Dienst, und MacroDroid hatte sich als eigener Prozess verbunden.

MacroDroid in Version 6.0.11 hält auf dem Gerät das Recht API_V23, gehört also zu den Apps, die Shizuku nutzen dürfen. Ob und wofür MacroDroid es dort verwendet, habe ich nicht untersucht. Ebenfalls installiert sind Tailscale und das Reverse-Tethering-Werkzeug gnirehtet. Das Tablet läuft per Wireless Debugging am Mac, zusätzlich per USB.

Einordnung: Was das für Admins und Bastler heisst

Shizuku macht aus einem Tablet ein Gerät, auf dem Apps mehr dürfen, ohne dass du es rootest. Das hilft bei kleinen Aufgaben: Befehle ausführen, Apps abschalten, den Bildschirm ohne Sperre löschen. Bei einem dauerhaften Kiosk gilt das als Risiko, weil der Dienst nach jedem Neustart neu gestartet werden muss und ein Mensch dafür nötig ist. Für verwaltete Firmengeräte ist Shizuku keine Lösung, weil es Richtlinien und Sperren umgeht, die eine Geräteverwaltung durchsetzt. Wer nur ein paar Rechte braucht, kommt mit pm grant aus, wie Teil 2 zu MacroDroid zeigt. Shizuku lohnt sich dort, wo eine App Befehle in der Shell ausführen soll.

Fazit

Shizuku bringt ADB-Rechte auf das Gerät, ohne Root und, ab Android 11, ohne Computer. Der Preis ist der Neustart: Nach jedem Boot startest du den Dienst erneut, und jeder App mit Zugriff vertraust du die Rechte der Shell an. Prüfen kannst du alles per ADB, wie das Skript zeigt. Den Einstieg der Reihe findest du im Artikel über den Nova Launcher.

Quellen: Shizuku: Einführung, Benutzerhandbuch, GitHub RikkaApps/Shizuku, Shizuku-API, Google Play, MacroDroid-Wiki, ADB-Dokumentation. Stand: 24. Oktober 2026.

Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion