Motivo del inicio canónico

Android 9 incluye los siguientes cambios en la especificación del motivo de inicio del bootloader.

Motivos de inicio

El bootloader usa recursos de hardware y memoria disponibles de manera única para determinar por qué se reinició un dispositivo y, luego, comunica esa determinación al agregando androidboot.bootreason=<reason> a Android de la línea de comandos de kernel para su lanzamiento. Luego, init traduce esto línea de comandos para propagarse a la propiedad de Android bootloader_boot_reason_prop (ro.boot.bootreason) En el caso de los dispositivos que se lanzan con Android 12 o versiones posteriores, haz lo siguiente: con la versión de kernel 5.10 o superior, androidboot.bootreason=<reason> se agrega a bootconfig en lugar de a la línea de comandos del kernel.

Especificaciones del motivo de inicio

En las versiones anteriores de Android, se especificaba un formato de motivo de inicio que no usaba espaciosos, estaba todo en minúsculas, tenía pocos requisitos (como la generación de informes kernel_panic, watchdog, cold/warm/hard), y que generaron permisos por otros motivos únicos. Esta especificación baja dio como resultado la la proliferación de cientos de motivos de inicio personalizados (y, a veces, sin sentido) cadenas, lo que a su vez conducía a una situación inmanejable. Hasta el momento Lanzamiento de Android, el gran impulso del contenido casi no analizable o sin sentido que archiva el bootloader creó problemas de cumplimiento bootloader_boot_reason_prop

Con la versión de Android 9, el equipo de Android reconoce que la bootloader_boot_reason_prop heredada tiene un impulso considerable y no se puede reescribir durante el tiempo de ejecución. Cualquier mejora en por lo tanto, la especificación del motivo de inicio debe provenir de interacciones con a los desarrolladores de bootloader y los ajustes al sistema existente. Con ese fin, la El equipo de Android:

• Interactúa con los desarrolladores de bootloader para alentarlos a hacer lo siguiente:
  • Proporciona razones canónicas, analizables y reconocibles para bootloader_boot_reason_prop
  • Participa en el system/core/bootstat/bootstat.cpp Lista kBootReasonMap.
• Agregar una fuente controlada y con capacidad de reescritura en el entorno de ejecución del system_boot_reason_prop (sys.boot.reason) R conjunto limitado de aplicaciones del sistema (como bootstat y init) puedes reescribir esta propiedad, pero todas las apps pueden otorgamiento de derechos de sepolicy para leerla.
• Informa a los usuarios sobre el motivo de inicio que deben esperar hasta que se activen los datos de usuario antes de confiar en el contenido de la propiedad del motivo de inicio del sistema system_boot_reason_prop

¿Por qué tan tarde? Si bien bootloader_boot_reason_prop está disponible con anticipación durante el inicio, la política de seguridad de Android la bloquea según sea necesario porque representa información imprecisa, no analizable y no canónica. En la mayoría de las situaciones, solo los desarrolladores con un conocimiento profundo del sistema de inicio necesitar para acceder a esta información. Un enfoque refinado, analizable y canónico La API por motivo de inicio con system_boot_reason_prop puede ser confiable y recopilarse con precisión solo después de que se activen los datos del usuario. Más precisamente:

• Antes de que se activen los datos de usuario system_boot_reason_prop contendrá el valor de bootloader_boot_reason_prop
• Después de que se activen los datos de usuario, Es posible que system_boot_reason_prop se actualice para cumplir con los requisitos o para brindar información más precisa.

Por este motivo, Android 9 extiende el período de tiempo antes de que el motivo de inicio se pueda adquirir oficialmente, lo que cambia de ser precisa de inmediato en el inicio (con bootloader_boot_reason_prop) solo estén disponibles después de que se activen los datos del usuario (con system_boot_reason_prop).

La lógica de arranque depende de un sistema más informativo bootloader_boot_reason_prop Cuando esa propiedad usa un más predecibles, mejora la precisión de todos los reinicios controlados y situaciones de cierre, lo que a su vez refina y expande la precisión y el significado de system_boot_reason_prop.

Formato del motivo de inicio canónico

El formato del motivo de inicio canónico de bootloader_boot_reason_prop En Android 9, usa la siguiente sintaxis:

<reason>,<subreason>,<detail>…

Reglas de formato:

• Minúscula
• Sin espacios en blanco (usar subrayado)
• Todos los caracteres imprimibles
• reason, subreason y uno o más separados por comas detail instancias más.
  • Un objeto reason obligatorio que representa la prioridad más alta el motivo por el que el dispositivo tuvo que reiniciarse o apagarse.
  • Un objeto subreason opcional que representa un breve resumen de por qué se tuvo que reiniciar o apagar el dispositivo (o quién reinició o apagó el dispositivo dispositivo).
  • Uno o más valores detail opcionales. Un detail pueden apuntar a un subsistema para ayudar a determinar qué sistema específico dio como resultado la subreason. Puedes especificar varias Valores detail, que por lo general deben seguir una jerarquía de importancia. Sin embargo, también es aceptable informar varias detail valores de igual importancia.

Se considera un valor vacío para bootloader_boot_reason_prop ilegal (ya que esto permite que otros agentes incorporen un motivo de inicio después del hecho)

Requisitos del motivo

El valor asignado para reason (primer intervalo, antes de la finalización o coma) debe ser del siguiente conjunto dividido en kernel, strong y blunt. motivos:

• kernel:
  • "watchdog"
  • "kernel_panic"
• conjunto sólido:
  • "recovery"
  • "bootloader"
• conjunto blunt:
  • "cold" Generalmente, indica un restablecimiento completo de todos los dispositivos. incluida la memoria.
  • "hard" Generalmente indica que el hardware tiene su estado restablecer, y ramoops debería conservar el contenido persistente.
  • "warm" Generalmente, indica la memoria y los dispositivos conserva algún estado, y el ramoops (consulta pstore de código fuente en el kernel) incluye contenido persistente.
  • "shutdown"
  • "reboot" Por lo general, significa que el estado ramoops es desconocido ni el estado del hardware. Este valor es genérico, ya que el valor Los valores cold, hard y warm proporcionan datos sobre la profundidad del restablecimiento del dispositivo.

Los bootloaders deben proporcionar un conjunto de kernels o un conjunto blunt reason, y te recomendamos que proporciones un subreason si se puede determinado. Por ejemplo, una tecla de encendido presionada La copia de seguridad de ramoops tendría el motivo del inicio "reboot,longkey"

Ningún reason del primer intervalo puede ser parte de cualquier subreason o detail Sin embargo, debido a que los motivos del conjunto de kernel no pueden ser producidos por espacio de usuario, es posible que se reutilice "watchdog" después de un motivo por el que no hay llanto. junto con un detalle de la fuente (por ejemplo, "reboot,watchdog,service_manager_unresponsive" o "reboot,software,watchdog").

Los motivos de inicio no deben requerir conocimientos internos expertos para descifrarlos o debe ser legible por humanos con un informe intuitivo. Ejemplos: "shutdown,vbxd" (mala), "shutdown,uv" (mejor), "shutdown,undervoltage" (opción preferida).

Combinaciones de motivo y submotivo

Android reserva un conjunto de reason a subreason. que no deben sobrecargarse en un uso normal, pero que pueden usarse caso por caso si la combinación refleja de manera precisa los atributos estado. Estos son algunos ejemplos de combinaciones reservadas:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (desde thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (desde BatteryStatsService)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

Para obtener más información, consulta kBootReasonMap en system/core/bootstat/bootstat.cpp y el Git asociado el historial de registros de cambios en el repositorio de código fuente de Android.

Informar motivos de inicio

Todos los motivos de inicio, ya sea desde el bootloader o registrado en el inicio canónico debe registrarse en la sección kBootReasonMap de system/core/bootstat/bootstat.cpp El La lista kBootReasonMap es una combinación de elementos compatibles y heredados por motivos de incumplimiento. Los desarrolladores de bootloader deben registrar solo de cumplimiento aquí (y no debe registrar los motivos de incumplimiento, a menos que el producto ya se envió y no se puede cambiar).

Recomendamos usar entradas existentes que cumplan con los requisitos en system/core/bootstat/bootstat.cpp y ejerciendo moderación antes con una cadena que no cumple con las políticas. A modo de lineamiento, debes cumplir con los siguientes requisitos:

• Aceptar para informar "kernel_panic" desde el bootloader, ya que bootstat puede inspeccionar ramoops de kernel_panic signatures para definir mejor la subrazones en la system_boot_reason_prop canónica.
• No es correcto informar una cadena que no cumple con las políticas en kBootReasonMap (como "panic") del bootloader, ya que, en última instancia, esto romperá la capacidad de definir mejor la reason

Por ejemplo, si kBootReasonMap contiene "wdog_bark", un desarrollador de bootloader debe hacer lo siguiente:

• Cambia a "watchdog,bark" y agrégalo a la lista en kBootReasonMap
• Considera lo que significa "bark" para aquellos que no estén familiarizados con el tecnología y determinar si una subreason más significativa es disponibles.

Verifica el cumplimiento del motivo de inicio

En este momento, Android no proporciona una prueba activa del CTS que pueda activar o inspeccionar todas las posibles razones de inicio que podría proporcionar un bootloader los socios pueden intentar ejecutar una prueba pasiva para determinar la compatibilidad.

Como resultado, el cumplimiento del bootloader requiere que los desarrolladores de bootloader cumplir voluntariamente con el espíritu de las reglas y los lineamientos descritos anteriormente. Instamos a estos desarrolladores a contribuir al AOSP (específicamente, a system/core/bootstat/bootstat.cpp) y utilice esta oportunidad como para debatir sobre problemas con el motivo de inicio.