Muchos usuarios dependen en gran medida de sus teléfonos y necesitan un dispositivo que funcione en todo momento. Sin embargo, a veces los dispositivos terminan en bucles de reinicio, lo que hace que los usuarios presenten tickets de soporte o consultas de garantía. Este proceso es frustrante para los usuarios y costoso para los fabricantes y operadores de dispositivos.
Android 8.0 incluye una función que envía un "grupo de rescate" cuando detecta componentes centrales del sistema atascados en bucles de bloqueo. Luego, Rescue Party avanza a través de una serie de acciones para recuperar el dispositivo. Como último recurso, Rescue Party reinicia el dispositivo en modo de recuperación y solicita al usuario que realice un restablecimiento de fábrica.
Estas funciones de rescate no son requeridas por el Documento de definición de compatibilidad de Android , pero aun así pueden ser útiles para reducir los casos de soporte.
Implementación
Rescue Party está habilitado de forma predeterminada en Android 8.0 y la implementación se encuentra en /services/core/java/com/android/server/RescueParty.java . Rescue Party recibe información sobre eventos de inicio y bloqueo y se inicia si:
- El system_server se reinicia más de 5 veces en 5 minutos.
- Una aplicación persistente del sistema falla más de 5 veces en 30 segundos.
Cuando se detecta una de estas situaciones, Rescue Party escala al siguiente nivel de rescate, procesa la tarea asociada con ese nivel y deja que el dispositivo continúe para ver si se recupera. Cada nivel es progresivamente más agresivo en lo que borra o reinicia. El nivel final solicita al usuario que restablezca el dispositivo a los valores de fábrica.
No se requiere soporte de hardware especial para admitir Rescue Party. Si se implementa, el sistema de recuperación de un dispositivo debe responder al comando --prompt_and_wipe_data y los dispositivos deben ofrecer a los usuarios una forma de confirmar cualquier destrucción de sus datos antes de continuar. El sistema de recuperación también debería darle al usuario la opción de intentar reiniciar su dispositivo nuevamente.
Debido a que cada nivel de rescate puede agregar hasta 5 minutos antes de que un dispositivo vuelva a estar operativo, los fabricantes de dispositivos no deben agregar niveles de rescate personalizados. El mayor tiempo con un dispositivo inoperable hace que sea más probable que los usuarios inicien una consulta de soporte o garantía en lugar de recuperar su dispositivo por sí mismos.
Validación
Todos los eventos de rescate se suprimen cuando el dispositivo tiene una conexión de datos USB activa porque es una señal fuerte de que alguien está depurando el dispositivo.
Para anular esta supresión, ejecute:
adb shell setprop persist.sys.enable_rescue 1
Desde allí, puede desencadenar un ciclo de falla del sistema o de la interfaz de usuario.
Para desencadenar un bucle de bloqueo system_server de bajo nivel, ejecute:
adb shell setprop debug.crash_system 1
Para desencadenar un bucle de bloqueo de SystemUI de nivel medio, ejecute:
adb shell setprop debug.crash_sysui 1
Ambos bucles de choque inician la lógica de rescate. Todas las operaciones de rescate también se registran en los registros persistentes de PackageManager almacenados en /data/system/uiderrors.txt para su posterior inspección y depuración. Estos registros persistentes también se incluyen en cada informe de error en la sección "Mensajes de advertencia del paquete".