Shizuku
13.5.4
Ao desenvolver aplicativos que requerem root, o método mais comum é executar alguns comandos no shell su. Por exemplo, existe um aplicativo que usa o comando pm enable/disable para ativar/desativar componentes.
Este método tem grandes desvantagens:
Shizuku usa uma maneira completamente diferente. Veja a descrição detalhada abaixo.
https://shizuku.rikka.app/
Primeiro, precisamos falar sobre como os aplicativos usam APIs do sistema. Por exemplo, se o aplicativo deseja instalar aplicativos, todos sabemos que devemos usar PackageManager#getInstalledPackages() . Na verdade, este é um processo de comunicação entre processos (IPC) do processo do aplicativo e do processo do servidor do sistema, apenas a estrutura do Android fez o trabalho interno para nós.
O Android usa binder para fazer esse tipo de IPC. Binder permite que o lado do servidor aprenda o uid e o pid do lado do cliente, para que o servidor do sistema possa verificar se o aplicativo tem permissão para realizar a operação.
Normalmente, se houver um "gerenciador" (por exemplo, PackageManager ) para uso dos aplicativos, deverá haver um "serviço" (por exemplo, PackageManagerService ) no processo do servidor do sistema. Podemos simplesmente pensar que se o aplicativo contém o binder do “serviço”, ele pode se comunicar com o “serviço”. O processo do aplicativo receberá fichários de serviços do sistema na inicialização.
Shizuku orienta os usuários a executar um processo, servidor Shizuku, com root ou ADB primeiro. Quando o aplicativo for iniciado, o binder do servidor Shizuku também será enviado ao aplicativo.
O recurso mais importante que Shizuku oferece é algo como ser um intermediário para receber solicitações do aplicativo, enviá-las ao servidor do sistema e enviar de volta os resultados. Você pode ver o método transactRemote na classe rikka.shizuku.server.ShizukuService e na classe moe.shizuku.api.ShizukuBinderWrapper para obter detalhes.
Assim, atingimos nosso objetivo, utilizar APIs de sistema com maior permissão. E para o aplicativo, é quase idêntico ao uso direto das APIs do sistema.
https://github.com/RikkaApps/Shizuku-API
Os aplicativos existentes ainda funcionam, é claro.
https://github.com/RikkaApps/Shizuku-API#migration-guide-for-existente-applications-use-shizuku-pre-v11
As permissões ADB são limitadas
ADB tem permissões limitadas e diferentes em várias versões do sistema. Você pode ver as permissões concedidas ao ADB aqui.
Antes de chamar a API, você pode usar ShizukuService#getUid para verificar se Shizuku está executando o usuário ADB ou usar ShizukuService#checkPermission para verificar se o servidor tem permissões suficientes.
Limitação de API oculta do Android 9
A partir do Android 9, o uso de APIs ocultas é limitado para aplicativos normais. Use outros métodos (como https://github.com/LSPosed/AndroidHiddenApiBypass).
Android 8.0 e ADB
Atualmente, a maneira como o serviço Shizuku obtém o processo do aplicativo é combinar IActivityManager#registerProcessObserver e IActivityManager#registerUidObserver (26+) para garantir que o processo do aplicativo seja enviado quando o aplicativo for iniciado. No entanto, na API 26, o ADB não possui permissões para usar registerUidObserver , portanto, se você precisar usar o Shizuku em um processo que pode não ser iniciado por uma atividade, é recomendável acionar o fichário de envio iniciando uma atividade transparente.
O uso direto de transactRemote requer atenção
A API pode ser diferente em diferentes versões do Android, verifique-a com atenção. Além disso, android.app.IActivityManager tem o formato aidl na API 26 e posterior, e android.app.IActivityManager$Stub existe apenas na API 26.
SystemServiceHelper.getTransactionCode pode não obter o código de transação correto, como android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages não existe na API 25 e existe android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages_47 (esta situação foi resolvida com, mas não está excluído que possa haver outras circunstâncias). Esse problema não é encontrado com o método ShizukuBinderWrapper .
git clone --recurse-submodules:manager:assembleDebug ou :manager:assembleRelease A tarefa :manager:assembleDebug gera um servidor depurável. Você pode anexar um depurador ao shizuku_server para depurar o servidor. Esteja ciente de que, no Android Studio, "Configurações de execução/depuração" - "Sempre instalar com gerenciador de pacotes" deve estar marcado, para que o servidor utilize o código mais recente.
O código deste projeto está disponível sob a licença Apache-2.0.
Você está PROIBIDO de usar os arquivos de imagem listados abaixo de qualquer forma (a menos que seja para exibir o próprio 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 o projeto como um todo, não é gratuito. Você está PROIBIDO de distribuir o apk compilado por você (incluindo modificado, por exemplo, renomear o nome do aplicativo "Shizuku" para outro nome) para qualquer loja (IBNLT Google Play Store, F-Droid, Amazon Appstore etc.).
