Muitos usuários dependem muito de seus telefones e precisam de um dispositivo funcionando o tempo todo. No entanto, às vezes os dispositivos acabam em loops de reinicialização, o que faz com que os usuários registrem tíquetes de suporte ou consultas de garantia. Esse processo é frustrante para os usuários e caro para fabricantes e operadoras de dispositivos.
O Android 8.0 inclui um recurso que envia uma “equipe de resgate” quando percebe componentes principais do sistema presos em loops de travamento. O Rescue Party então passa por uma série de ações para recuperar o dispositivo. Como último recurso, o Rescue Party reinicia o dispositivo no modo de recuperação e solicita que o usuário execute uma redefinição de fábrica.
Esses recursos de resgate não são exigidos pelo Documento de definição de compatibilidade do Android , mas ainda podem ser úteis para reduzir casos de suporte.
Implementação
O Rescue Party está habilitado por padrão no Android 8.0, e a implementação reside em /services/core/java/com/android/server/RescueParty.java . O Rescue Party recebe informações sobre eventos de inicialização e travamento e inicia se:
- O system_server reinicia mais de 5 vezes em 5 minutos.
- Um aplicativo de sistema persistente trava mais de 5 vezes em 30 segundos.
Quando uma dessas situações é detectada, o Rescue Party escala para o próximo nível de resgate, processa a tarefa associada a esse nível e permite que o dispositivo prossiga para ver se ele se recupera. Cada nível é progressivamente mais agressivo naquilo que limpa ou reinicia. O nível final solicita que o usuário redefina o dispositivo para os padrões de fábrica.
Nenhum suporte de hardware especial é necessário para oferecer suporte ao Rescue Party. Se implementado, o sistema de recuperação de um dispositivo deve responder ao comando --prompt_and_wipe_data e os dispositivos devem revelar uma maneira para os usuários confirmarem qualquer destruição de dados do usuário antes de prosseguir. O sistema de recuperação também deve dar ao usuário a opção de tentar inicializar o dispositivo novamente.
Como cada nível de resgate pode adicionar até 5 minutos antes que um dispositivo volte a funcionar, os fabricantes de dispositivos não devem adicionar níveis de resgate personalizados. O aumento do tempo com um dispositivo inoperante aumenta a probabilidade de os usuários iniciarem uma consulta de suporte ou garantia em vez de recuperarem o dispositivo por conta própria.
Validação
Todos os eventos de resgate são suprimidos quando o dispositivo tem uma conexão de dados USB ativa, pois isso é um sinal forte de que alguém está depurando o dispositivo.
Para substituir essa supressão, execute:
adb shell setprop persist.sys.enable_rescue 1
A partir daí, você pode acionar um loop de travamento do sistema ou da interface do usuário.
Para acionar um loop de travamento system_server de baixo nível, execute:
adb shell setprop debug.crash_system 1
Para acionar um loop de travamento SystemUI de nível médio, execute:
adb shell setprop debug.crash_sysui 1
Ambos os loops de travamento iniciam a lógica de resgate. Todas as operações de resgate também são registradas nos logs persistentes do PackageManager armazenados em /data/system/uiderrors.txt para inspeção e depuração posteriores. Esses logs persistentes também estão incluídos em todos os relatórios de bugs na seção "Mensagens de aviso de pacote".