Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Razón de arranque canónica

Android 9 incluye los siguientes cambios en la especificación del motivo de arranque del cargador de arranque.

Razones de arranque

Hardware y recursos de memoria A utiliza el cargador de manera exclusiva y disponibles para determinar por qué un dispositivo de reiniciado, a continuación, se comunica que la determinación mediante la adición de androidboot.bootreason=<reason> a la línea de comandos del kernel de Android para su lanzamiento. init luego se traduce esta línea de comandos se propaguen a la propiedad Android bootloader_boot_reason_prop ( ro.boot.bootreason ). Para los dispositivos de puesta a flote con Android 12 o posterior, utilizando la versión del kernel 5.10 o mayor, androidboot.bootreason=<reason> se añade a bootconfig en lugar de la línea de comandos del kernel.

Especificaciones del motivo de arranque

Las versiones anteriores de Android especifican un formato razón de arranque que utiliza sin espacios, era todo en minúsculas, incluidos algunos requisitos (por ejemplo, para informar kernel_panic , watchdog , cold / warm / hard ), y que tuvieron en cuenta por otras razones únicas. Esta especificación flexible dio como resultado la proliferación de cientos de cadenas de motivos de arranque personalizadas (y a veces sin sentido), lo que a su vez condujo a una situación inmanejable. A partir de la versión actual de Android, el gran impulso del contenido unparseable o sin sentido cerca interpuesta por el cargador de arranque ha creado problemas de cumplimiento para bootloader_boot_reason_prop .

Con el lanzamiento de Android 9, el equipo de Android reconoce que el legado bootloader_boot_reason_prop tiene un impulso considerable y no puede ser re-escrito en tiempo de ejecución. Por lo tanto, cualquier mejora en la especificación del motivo de arranque debe provenir de interacciones con los desarrolladores del cargador de arranque y ajustes al sistema existente. Con ese fin, el equipo de Android es:

  • Comprometerse con los desarrolladores de cargadores de arranque para animarlos a:
    • Proporcionar razones canónicas, analizable y reconocibles a bootloader_boot_reason_prop .
    • Participar en el system/core/bootstat/bootstat.cpp kBootReasonMap lista.
  • Adición de una fuente controlada y tiempo de ejecución regrabable de la system_boot_reason_prop ( sys.boot.reason ). Un conjunto limitado de aplicaciones del sistema (como bootstat y init ) se puede reescribir esta propiedad, pero todas las aplicaciones se pueden conceder derechos sepolicy para leerlo.
  • Informando a los usuarios de la razón de arranque que esperar hasta después de los datos de usuario se monta antes de confiar en el contenido en el arranque del sistema de propiedad razón system_boot_reason_prop .

¿Por qué tan tarde? Mientras bootloader_boot_reason_prop está disponible desde el principio en el arranque, éste se encuentra bloqueado por la política de seguridad de Android sobre una base como-necesidad, ya que representa la información inexacta, unparseable, y no canónica. En la mayoría de las situaciones, solo los desarrolladores con un conocimiento profundo del sistema de arranque deberían tener acceso a esta información. Un refinado, analizable y API canónica para la razón de arranque a través de system_boot_reason_prop se pueden recoger de forma fiable y con precisión sólo después de los datos de usuario se ha montado. Específicamente:

  • Antes de los datos de usuario se ha montado, system_boot_reason_prop contendrá el valor de bootloader_boot_reason_prop .
  • Después de los datos de usuario se ha montado, system_boot_reason_prop puede ser actualizado para que sea compatible o para informar de una información más precisa.

Por esta razón, Android 9 se extiende el período de tiempo antes de que la razón de arranque puede ser adquirido oficialmente, cambiándolo de ser inmediatamente exacta en el arranque (con bootloader_boot_reason_prop ) de estar disponible sólo después de que los datos de usuario se ha montado (con system_boot_reason_prop ).

Bootstat lógica depende de una más informativo y compatible bootloader_boot_reason_prop . Cuando esa propiedad utiliza un formato predecible, mejora la exactitud de todos los escenarios de reinicio y apagado controlado, lo que a su vez refina y amplía la exactitud y el significado de system_boot_reason_prop .

Formato de motivo de arranque canónico

El formato de arranque razón canónica para bootloader_boot_reason_prop en Android 9 usa la siguiente sintaxis:

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

Reglas de formato:

  • Minúscula
  • Sin espacios en blanco (use subrayado)
  • Todos los personajes imprimibles
  • Separada por comas reason , subreason , y uno o más detail (s).
    • Un requerida reason que representa la razón más alta prioridad por qué el dispositivo tuvo que reinicio o apagado.
    • Un opcional subreason que representa un breve resumen de por qué el dispositivo tuvo que reinicio o apagado (o que reinicia o apagar el dispositivo).
    • Uno o más opcionales detail valores. Un detail puede apuntar a un subsistema para ayudar en la determinación de qué sistema específico dado lugar a la subreason . Se pueden especificar varios detail valores, que generalmente deben seguir una jerarquía de importancia. Sin embargo, también es aceptable para reportar múltiples detail valores de igual importancia.

Un valor vacío para bootloader_boot_reason_prop se considera ilegal (ya que esto permite que otros agentes para inyectar una razón de arranque después de los hechos).

Requisitos de la razón

El valor dado para la reason (primer tramo, antes de la terminación o la coma) debe ser de la siguiente conjunto dividido en kernel, fuertes y contundentes razones:

  • conjunto de núcleos:
    • " watchdog"
    • "kernel_panic"
  • conjunto fuerte:
    • "recovery"
    • "bootloader"
  • conjunto contundente:
    • "cold" . Generalmente indica un reinicio completo de todos los dispositivos, incluida la memoria.
    • "hard" . En general, indica que el hardware tiene su restablecimiento del estado y ramoops debe retener el contenido persistente.
    • "warm" . Generalmente indica que la memoria y los dispositivos retienen algún estado, y los ramoops (véase pstore conductor en kernel) almacén de respaldo contiene contenido persistente.
    • "shutdown"
    • "reboot" . Por lo general significa que el ramoops estado es desconocido y el estado del hardware es desconocida. Este valor es un catchall como el cold , hard , y warm valores proporcionan pistas en cuanto a la profundidad de la reposición para el dispositivo.

Gestores de arranque deben proporcionar un conjunto de núcleo o un conjunto romo reason , y se les anima fuertemente a proporcionar una subreason si puede ser determinada. Por ejemplo, una tecla de encendido pulsación larga que pueden o no pueden tener ramoops copia de seguridad tendría la razón de arranque "reboot,longkey" .

Sin primera lapso de reason puede ser parte de cualquier subreason o detail . Sin embargo, debido razones expuestas núcleo no pueden ser producidos por el espacio de usuario, "watchdog" puede ser reutilizado después de una razón conjunto romo, junto con un detalle de la fuente (por ejemplo "reboot,watchdog,service_manager_unresponsive" , o "reboot,software,watchdog" ).

Los motivos de arranque no deben requerir conocimientos internos expertos para descifrarlos y / o deben ser legibles por humanos con un informe intuitivo. Ejemplos: "shutdown,vbxd" (malo), "shutdown,uv" (mejor), "shutdown,undervoltage" (preferido).

Combinaciones de motivo y subtemporada

Android reservas un conjunto de reason - subreason combinaciones que no debe ser sobrecargado en el uso normal, pero se puede utilizar en una base de caso por caso si la combinación refleja con precisión la condición de asociado. Ejemplos de combinaciones reservadas incluyen:

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

Para más detalles, consulte kBootReasonMap en system/core/bootstat/bootstat.cpp y la historia git cambios asociados en el repositorio de código fuente de Android.

Informar motivos de arranque

Todas las razones de arranque, ya sea desde el gestor de arranque o registrados en la razón de arranque canónica, debe ser registrado en el kBootReasonMap sección del system/core/bootstat/bootstat.cpp . El kBootReasonMap lista es una mezcla de razones conformes y no conformes legado. Los desarrolladores del cargador de arranque deben registrar aquí solo los nuevos motivos de cumplimiento (y no deben registrar los motivos de incumplimiento a menos que el producto ya se haya enviado y no se pueda cambiar).

Se recomienda encarecidamente el uso de las entradas existentes, que cumplen en system/core/bootstat/bootstat.cpp y ejercer moderación antes de usar una cadena no conforme. Como pauta, es:

  • Aceptar para informar "kernel_panic" del gestor de arranque, como bootstat puede ser capaz de inspeccionar ramoops para kernel_panic signatures para refinar los subreasons en el canónica system_boot_reason_prop .
  • NO se puede reportar una cadena no conforme en kBootReasonMap (como el "panic") desde el gestor de arranque, ya que esto en última instancia, romper la capacidad de refinar la reason .

Por ejemplo, si kBootReasonMap contiene "wdog_bark" , un desarrollador cargador de arranque debe:

  • Cambio de "watchdog,bark" y añadir a la lista de kBootReasonMap .
  • Considerar que "bark" medios para quienes no están familiarizados con la tecnología y determinar si un mayor significado subreason está disponible.

Verificación del cumplimiento del motivo de inicio

En este momento, Android no proporciona una prueba CTS activa que pueda activar o inspeccionar con precisión todas las posibles razones de arranque que podría proporcionar un cargador de arranque; los socios aún pueden intentar ejecutar una prueba pasiva para determinar la compatibilidad.

Como resultado, el cumplimiento del cargador de arranque requiere que los desarrolladores del cargador de arranque se adhieran voluntariamente al espíritu de las reglas y pautas descritas anteriormente. Instamos a dichos desarrolladores para contribuir a AOSP (específicamente al system/core/bootstat/bootstat.cpp ) y aprovechar esta oportunidad como un foro de debate sobre cuestiones razón de arranque.