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 um "grupo de resgate" quando percebe componentes centrais do sistema presos em loops de falha. A Equipe de Resgate então escala por meio de uma série de ações para recuperar o dispositivo. Como último recurso, o Rescue Party reinicializa 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 os casos de suporte.
Implementação
O Rescue Party é ativado 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 é reiniciado 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 no que limpa ou reinicia. O nível final solicita que o usuário redefina o dispositivo de fábrica.
Nenhum suporte de hardware especial é necessário para dar 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 apresentar uma maneira para os usuários confirmarem qualquer destruição de dados do usuário antes de continuar. O sistema de recuperação também deve dar ao usuário a opção de tentar inicializar seu 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 torna os usuários mais propensos a iniciar uma consulta de suporte ou garantia em vez de auto-recuperar seu dispositivo.
Validação
Todos os eventos de resgate são suprimidos quando o dispositivo tem uma conexão de dados USB ativa porque isso é um forte sinal 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 falha do sistema ou da interface do usuário.
Para acionar um loop de falha do system_server de baixo nível, execute:
adb shell setprop debug.crash_system 1
Para acionar um loop de falha do SystemUI de nível médio, execute:
adb shell setprop debug.crash_sysui 1
Ambos os loops de falha 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 são incluídos em todos os relatórios de bugs na seção "Mensagens de aviso do pacote".