Shizuku
13.5.4
Al desarrollar aplicaciones que requieren root, el método más común es ejecutar algunos comandos en su shell. Por ejemplo, hay una aplicación que utiliza el comando pm enable/disable para habilitar/deshabilitar componentes.
Este método tiene desventajas muy grandes:
Shizuku usa una forma completamente diferente. Vea la descripción detallada a continuación.
https://shizuku.rikka.app/
Primero, debemos hablar sobre cómo las aplicaciones utilizan las API del sistema. Por ejemplo, si la aplicación quiere instalar aplicaciones, todos sabemos que debemos usar PackageManager#getInstalledPackages() . En realidad, este es un proceso de comunicación entre procesos (IPC) del proceso de la aplicación y el proceso del servidor del sistema, solo el marco de Android hizo el trabajo interno por nosotros.
Android usa binder para realizar este tipo de IPC. Binder permite que el lado del servidor conozca el uid y el pid del lado del cliente, de modo que el servidor del sistema pueda verificar si la aplicación tiene permiso para realizar la operación.
Por lo general, si hay un "administrador" (por ejemplo, PackageManager ) para que lo utilicen las aplicaciones, debería haber un "servicio" (por ejemplo, PackageManagerService ) en el proceso del servidor del sistema. Simplemente podemos pensar que si la aplicación contiene la binder del "servicio", puede comunicarse con el "servicio". El proceso de la aplicación recibirá carpetas de servicios del sistema al inicio.
Shizuku guía a los usuarios para ejecutar un proceso, el servidor Shizuku, primero con root o ADB. Cuando se inicia la aplicación, la binder del servidor Shizuku también se enviará a la aplicación.
La característica más importante que ofrece Shizuku es algo así como ser un intermediario para recibir solicitudes de la aplicación, enviarlas al servidor del sistema y devolver los resultados. Puede ver el método transactRemote en la clase rikka.shizuku.server.ShizukuService y en la clase moe.shizuku.api.ShizukuBinderWrapper para obtener más detalles.
Entonces, alcanzamos nuestro objetivo: utilizar API del sistema con mayor permiso. Y para la aplicación, es casi idéntico al uso directo de las API del sistema.
https://github.com/RikkaApps/Shizuku-API
Por supuesto, las aplicaciones existentes todavía funcionan.
https://github.com/RikkaApps/Shizuku-API#migration-guide-for-existing-applications-use-shizuku-pre-v11
Los permisos de ADB son limitados
ADB tiene permisos limitados y diferentes en varias versiones del sistema. Puede ver los permisos otorgados a ADB aquí.
Antes de llamar a la API, puede usar ShizukuService#getUid para verificar si Shizuku está ejecutando el usuario ADB, o usar ShizukuService#checkPermission para verificar si el servidor tiene permisos suficientes.
Limitación de API oculta de Android 9
A partir de Android 9, el uso de API ocultas está limitado para aplicaciones normales. Utilice otros métodos (como https://github.com/LSPosed/AndroidHiddenApiBypass).
Android 8.0 y BAD
En la actualidad, la forma en que el servicio Shizuku obtiene el proceso de la aplicación es combinar IActivityManager#registerProcessObserver e IActivityManager#registerUidObserver (26+) para garantizar que el proceso de la aplicación se envíe cuando se inicie la aplicación. Sin embargo, en API 26, ADB carece de permisos para usar registerUidObserver , por lo que si necesita usar Shizuku en un proceso que podría no ser iniciado por una actividad, se recomienda activar la carpeta de envío iniciando una actividad transparente.
El uso directo de transactRemote requiere atención
La API puede ser diferente según las diferentes versiones de Android; asegúrese de verificarla detenidamente. Además, android.app.IActivityManager tiene el formato Aidl en API 26 y versiones posteriores, y android.app.IActivityManager$Stub solo existe en API 26.
Es posible que SystemServiceHelper.getTransactionCode no obtenga el código de transacción correcto, como android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages no existe en API 25 y existe android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages_47 (esta situación ya se ha solucionado) con, pero no se excluye que puedan existir otras circunstancias). Este problema no se encuentra con el método ShizukuBinderWrapper .
git clone --recurse-submodules:manager:assembleDebug o :manager:assembleRelease La tarea :manager:assembleDebug genera un servidor depurable. Puede adjuntar un depurador a shizuku_server para depurar el servidor. Tenga en cuenta que, en Android Studio, se debe marcar "Configuraciones de ejecución/depuración" - "Instalar siempre con el administrador de paquetes", para que el servidor utilice el código más reciente.
El código de este proyecto está disponible bajo la licencia Apache-2.0.
Está PROHIBIDO utilizar los archivos de imágenes que se enumeran a continuación de cualquier manera (a menos que sea para mostrar Shizuku).
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
Para el proyecto en su conjunto, no es gratuito. Tiene PROHIBIDO distribuir el apk compilado por usted (incluido el modificado, por ejemplo, cambiar el nombre de la aplicación "Shizuku" a otro) en cualquier tienda (IBNLT Google Play Store, F-Droid, Amazon Appstore, etc.).
