Shizuku
13.5.4
Bei der Entwicklung von Apps, die Root erfordern, besteht die häufigste Methode darin, einige Befehle in der su-Shell auszuführen. Beispielsweise gibt es eine App, die den Befehl pm enable/disable verwendet, um Komponenten zu aktivieren/deaktivieren.
Diese Methode hat sehr große Nachteile:
Shizuku geht einen völlig anderen Weg. Siehe detaillierte Beschreibung unten.
https://shizuku.rikka.app/
Zuerst müssen wir darüber sprechen, wie Apps System-APIs verwenden. Wenn die App beispielsweise installierte Apps erhalten möchte, sollten wir alle wissen, dass wir PackageManager#getInstalledPackages() verwenden sollten. Dabei handelt es sich eigentlich um einen Interprozesskommunikationsprozess (IPC) des App-Prozesses und des Systemserverprozesses, nur das Android-Framework hat die inneren Arbeiten für uns erledigt.
Android verwendet binder für diese Art von IPC. Binder ermöglicht es der Serverseite, die UID und PID der Clientseite zu lernen, sodass der Systemserver prüfen kann, ob die App die Berechtigung zum Ausführen des Vorgangs hat.
Wenn es einen „Manager“ (z. B. PackageManager ) für die Verwendung durch Apps gibt, sollte es normalerweise einen „Dienst“ (z. B. PackageManagerService ) im Systemserverprozess geben. Wir können uns einfach vorstellen, dass die App mit dem „Dienst“ kommunizieren kann, wenn sie den binder des „Dienstes“ enthält. Der App-Prozess erhält beim Start Ordner mit Systemdiensten.
Shizuku führt Benutzer dazu, einen Prozess, einen Shizuku-Server, zuerst mit Root oder ADB auszuführen. Wenn die App startet, wird auch der binder zum Shizuku-Server an die App gesendet.
Die wichtigste Funktion, die Shizuku bietet, besteht darin, als Mittelsmann Anfragen von der App entgegenzunehmen, sie an den Systemserver zu senden und die Ergebnisse zurückzusenden. Einzelheiten finden Sie in der transactRemote -Methode in der Klasse rikka.shizuku.server.ShizukuService und in der Klasse moe.shizuku.api.ShizukuBinderWrapper .
Damit haben wir unser Ziel erreicht, System-APIs mit höheren Berechtigungen zu verwenden. Und für die App ist es fast identisch mit der direkten Verwendung von System-APIs.
https://github.com/RikkaApps/Shizuku-API
Bestehende Anwendungen funktionieren natürlich weiterhin.
https://github.com/RikkaApps/Shizuku-API#migration-guide-for-existing-applications-use-shizuku-pre-v11
ADB-Berechtigungen sind begrenzt
ADB verfügt über begrenzte Berechtigungen und ist je nach Systemversion unterschiedlich. Hier können Sie die ADB gewährten Berechtigungen sehen.
Bevor Sie die API aufrufen, können Sie mit ShizukuService#getUid prüfen, ob Shizuku den Benutzer ADB ausführt, oder mit ShizukuService#checkPermission prüfen, ob der Server über ausreichende Berechtigungen verfügt.
Versteckte API-Einschränkung von Android 9
Ab Android 9 ist die Nutzung der versteckten APIs für normale Apps eingeschränkt. Bitte verwenden Sie andere Methoden (z. B. https://github.com/LSPosed/AndroidHiddenApiBypass).
Android 8.0 und ADB
Derzeit erhält der Shizuku-Dienst den App-Prozess durch die Kombination von IActivityManager#registerProcessObserver und IActivityManager#registerUidObserver (26+), um sicherzustellen, dass der App-Prozess beim Start der App gesendet wird. Bei API 26 fehlt ADB jedoch die Berechtigung zur Verwendung registerUidObserver . Wenn Sie Shizuku also in einem Prozess verwenden müssen, der möglicherweise nicht durch eine Aktivität gestartet wird, wird empfohlen, den Sendebinder durch Starten einer transparenten Aktivität auszulösen.
Die direkte Verwendung von transactRemote erfordert Aufmerksamkeit
Die API kann je nach Android-Version unterschiedlich sein. Bitte überprüfen Sie sie sorgfältig. Außerdem verfügt der android.app.IActivityManager über die Hilfsform in API 26 und höher, und android.app.IActivityManager$Stub existiert nur in API 26.
SystemServiceHelper.getTransactionCode erhält möglicherweise nicht den richtigen Transaktionscode, z. B. android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages existiert nicht auf API 25 und es gibt android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages_47 (diese Situation wurde behoben). mit, es ist jedoch nicht ausgeschlossen, dass auch andere Umstände vorliegen können). Dieses Problem tritt bei der ShizukuBinderWrapper -Methode nicht auf.
git clone --recurse-submodules:manager:assembleDebug oder :manager:assembleRelease aus Die Aufgabe :manager:assembleDebug generiert einen debuggbaren Server. Sie können einen Debugger an shizuku_server anhängen, um den Server zu debuggen. Beachten Sie, dass in Android Studio „Konfigurationen ausführen/debuggen“ – „Immer mit Paketmanager installieren“ aktiviert sein sollte, damit der Server den neuesten Code verwendet.
Der Code für dieses Projekt ist unter der Apache-2.0-Lizenz verfügbar.
Es ist Ihnen VERBOTEN , die unten aufgeführten Bilddateien in irgendeiner Weise zu verwenden (außer zur Darstellung von Shizuku selbst).
manager/src/main/res/mipmap-hdpi/ic_launcher.png
manager/src/main/res/mipmap-hdpi/ic_launcher_background.png
manager/src/main/res/mipmap-hdpi/ic_launcher_foreground.png
manager/src/main/res/mipmap-xhdpi/ic_launcher.png
manager/src/main/res/mipmap-xhdpi/ic_launcher_background.png
manager/src/main/res/mipmap-xhdpi/ic_launcher_foreground.png
manager/src/main/res/mipmap-xxhdpi/ic_launcher.png
manager/src/main/res/mipmap-xxhdpi/ic_launcher_background.png
manager/src/main/res/mipmap-xxhdpi/ic_launcher_foreground.png
manager/src/main/res/mipmap-xxxhdpi/ic_launcher.png
manager/src/main/res/mipmap-xxxhdpi/ic_launcher_background.png
manager/src/main/res/mipmap-xxxhdpi/ic_launcher_foreground.png
Für das Projekt als Ganzes ist es nicht kostenlos. Es ist Ihnen VERBOTEN, die von Ihnen kompilierte APK (einschließlich geänderter, z. B. Umbenennung des App-Namens „Shizuku“ in etwas anderes) an einen Store (IBNLT Google Play Store, F-Droid, Amazon Appstore usw.) zu verteilen.
