Apesar do entusiasmo inicial, o Rescue Party do Android Oreo não é a solução de bootloop que você procurava. Aqui está uma explicação do que ele realmente faz.
No XDA, cobrimos extensivamente a versão mais recente do sistema operacional Android do Google: Android 8.0 Oreo. O Android Oreo traz uma série de novos recursos, mas os que mais nos entusiasmam são as mudanças ocultas. Coisas como Projeto Agudos e suporte a temas personalizados em todo o sistema são dois exemplos de mudanças relacionadas ao Android Oreo que interessam aos nossos leitores. Outro recurso que os entusiastas do Android estão ansiosos para ver em ação é o novo Festa de Resgate recurso. Esse recurso foi elogiado por muitos para salvar seu dispositivo de um bootloop, mas a realidade é muito mais decepcionante. Rescue Party não é a correção de bootloop que você estava procurando.
Na realidade, o Rescue Party só funciona em uma situação muito limitada, que dificilmente será importante para muitos usuários cujos dispositivos entram em bootloop. Isto é especialmente verdadeiro para quase todos os usuários em nosso fórum que encontram um bootloop – o Rescue Party não irá ajudá-lo. Mas isso não é culpa do Rescue Party, porque ele foi muito mais divulgado do que deveria, considerando o que realmente faz.
Festa de resgate no Android Oreo – como funciona
Vamos começar explicando como o Rescue Party é acionado. Em primeiro lugar, o Rescue Party precisa ser implementado, o que não é exigido pelos OEMs. Em dispositivos com suporte ao Rescue Party, a primeira verificação que acontece é se o recurso está habilitado, o que pode não ser o caso se o dispositivo estiver sendo executado em uma compilação de depuração/engenharia ou se a propriedade do sistema persist.sys.disable_rescue está definido como verdadeiro em build.prop.
Depois de peças mínimas do sistema operacional Android foi iniciado durante o processo de inicialização, o sistema determina se precisa enviar um Rescue Party. Como você já deve ter lido antes, um Grupo de Resgate é enviado sempre que o dispositivo reinicia mais de 5 vezes em 5 minutos ou um aplicativo do sistema trava mais de 5 vezes em 30 segundos. Equipe de Resgate então começa a incremento através de vários "níveis de resgate" na tentativa de consertar o loop de reinicialização.
Aqui está o passos que o Grupo de Resgate pode levar:
Nível 1 – Redefinir padrões não confiáveis
O primeiro nível do Rescue Party é reiniciar toda e qualquer alteração no Configurações. Global ou Configurações. Seguro tabelas de preferências criadas por aplicativos não confiáveis. Aplicativos não confiáveis são aqueles pacotes instalados pelo usuário. Quando este nível do Rescue Party é chamado, qualquer alteração feita por um aplicativo de terceiros será substituída pelo seu valor padrão, se existir. Se não existir um valor padrão, a configuração será excluída.
A única maneira de um aplicativo não confiável poder modificar um valor de configuração em Global ou Seguro é se esse aplicativo tiver acesso root ou tiver recebido o WRITE_SECURE_SETTINGS permissão via ADB. Esta não é uma situação tão incomum, já que muitos de nossos próprios tutoriais não-root dependem fortemente da modificação desses bancos de dados de configuração da mesma maneira.
Um exemplo deste nível do Grupo de Resgate em jogo seria se o usuário estivesse tentando personalize sua barra de navegação no Android Oreo. Fazer isso exigiria modificar Settings.Secure.sysui_nav_bar por meio de um aplicativo de terceiros, como Barra de navegação personalizada. Agora, é improvável que modificar a barra de navegação através deste método cause um bootloop, mas se isso acontecesse, então este O nível do Rescue Party redefiniria qualquer alteração feita e a substituiria pelo valor padrão de sysui_nav_bar qual é "left, back; home; recent, right".
Nível 2 – Redefinir alterações não confiáveis
A segunda tentativa de corrigir o problema de reinicialização é levar o nível 1 um passo adiante. Em vez de apenas redefinir quaisquer valores de configuração feitos por pacotes não confiáveis, ele excluirá todos eles completamente.
Nível 3 – Redefinir padrões confiáveis
A última linha de defesa contra bootloops oferecida pelo Rescue Party, nível 3, redefinirá todas as alterações feitas nas configurações. Global ou Configurações. Valor seguro que foi feito por confiável, ou seja. sistema, aplicativos. Ele também tenta as alterações feitas pelos níveis anteriores, como a exclusão de alterações feitas por pacotes não confiáveis.
Nível 4 - Redefinição de fábrica
Se tudo mais falhar, a última tentativa de consertar seu dispositivo é inicializar a recuperação e solicitar que o usuário execute uma redefinição de fábrica. Embora esta ação provavelmente resolva o bootloop (desde que o bootloop não seja causado por problemas de hardware como no Nexus 5X ou Nexus 6P), obviamente não é o ideal, pois envolve configurar o telefone novamente.
Não é uma correção de Bootloop para você
Então, vamos resumir o que o Rescue Party realmente faz. Essencialmente, tudo o que ele faz é tentar corrigir quaisquer alterações erradas feitas pelo usuário ou por aplicativos do sistema nas Configurações. Global ou Configurações. Tabela de preferências seguras. Se o seu dispositivo entrar em um bootloop porque você atualizou um mod de áudio com falha, instalou o tema Substratum errado, ativou um Magisk/Xposed módulo que não era para você, fez uma edição ruim do build.prop ou fez qualquer uma das inúmeras coisas que um usuário rooteado pode fazer para entrar em um bootloop, então A Festa de Resgate não é para você.
Se você de alguma forma, acabará em um loop de reinicialização, modificando uma configuração como "Simular monitores secundários" nas Opções do desenvolvedor, só então o Rescue Party realmente o ajudaria. Mas eu suponho que a grande maioria dos nossos leitores provavelmente não terá seus bootloops resolvidos através do Rescue Party. Infelizmente, a melhor maneira de lidar com bootloops é mantenha backup dos seus dados regularmente, para que você nunca precise lidar com perdas catastróficas de dados em seu telefone. Não conte com Rescue Party para ser seu salvador.