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

Requisitos del núcleo del núcleo

Android 8.0 y superior exigen una versión y una configuración de kernel mínimas, que son verificadas por Vendor Test Suite (VTS) y actualizaciones inalámbricas (OTA). Núcleos de dispositivos Android deben permitir kernel .config apoyo y la opción de leer la configuración del kernel en tiempo de ejecución a través de la procfs sistema de archivos.

Compatibilidad con kernel .config

Todos los núcleos de dispositivos deben permitir la totalidad de android-base.cfg , que debe incluir las siguientes opciones de configuración del kernel (o su equivalente kernel-version):

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Versión del núcleo

Para Android 9, los requisitos mínimos de la versión del kernel de soporte a largo plazo (LTS) son 4.4.107, 4.9.84 y 4.14.42.

  • Todos los SoC producidos en 2018 deben lanzarse con el kernel 4.9.84 o superior.
  • Todos los demás SoC que ejecutan dispositivos Android que ejecutan Android 9 deben usar el kernel 4.4.107 o superior.
  • Los núcleos de dispositivos basados ​​en 4.14 deben incluir la versión 4.14.42 o superior de LTS.
  • Independientemente de la fecha de lanzamiento, todos los SoC con lanzamientos de dispositivos en Android 8.0 y superior siguen sujetos a los cambios del kernel necesarios para habilitar Treble.
  • Los dispositivos Android más antiguos que se actualizan a Android 8.0 o superior pueden seguir usando su versión de kernel base original.

Para más detalles sobre los núcleos LTS, consulte los núcleos estables a largo plazo y Android Común núcleos

Soporte de Devicetree

Si la plataforma no admite la configuración avanzada e interfaz de energía (ACPI) especificación, devicetree soporte en el kernel debe estar habilitado y gestores de arranque debe pasar a la descripción de hardware en forma de un devicetree al núcleo. El árbol de dispositivos también debe estar disponible para que Android lo lea, y debe poder pasar parámetros específicos del proveedor y de ODM a Android. CONFIG_OF es obligatoria, junto con todos los demás y de dispositivo específicos del subsistema CONFIG_OF_* opciones de configuración del núcleo.

Usando DebugFS

La implementación de la interfaz de proveedor no puede confiar en la DebugFS sistema de archivos para acceder a la información de depuración. Eso es porque en Android 7,0 a 10, DebugFS se puede activar, pero las pruebas VTS podría hacerse con DebugFS sin montar.

En Android 11, DebugFS no se puede acceder o montados en dispositivos de producción, por lo que los fabricantes de dispositivos deben quitarlo. Antes de Android 11, dumpstate acceder a las estadísticas de aglutinante de DebugFS . Debido usuario construye botadura con Android 11 o superior no puede tener acceso DebugFS , dumpstate accesos de aglutinante estadísticas de binderfs . Para habilitar Binderfs , permitirá a la configuración del núcleo CONFIG_ANDROID_BINDERFS .

En Android 11, VTS aplica estos dos requisitos:

  • CONFIG_DEBUG_FS no está habilitada en la configuración del núcleo del dispositivo.
  • DebugFS no aparece en /proc/filesystems .

DebugFS en Android 12

Los dispositivos que se inician con Android 12 con versiones de kernel superiores a la v5.4 deben enviarse con el kernel GKI. Por lo que los socios pueden acceder DebugFS de depuración de usuario construye mientras desarrollan en el GKI kernel, la configuración del núcleo CONFIG_DEBUG_FS está habilitada en el defconfig GKI. Nunca monte DebugFS de usuario construye para los dispositivos de puesta a flote tanto en Android 11 y 12 Android.

Las compilaciones de Userdebug tienen una mejor cobertura de prueba que las compilaciones de usuario y se someten a pruebas exhaustivas durante todo el ciclo de desarrollo. El siguiente plan minimiza la diferencia entre los dos tipos de construcción con respecto a DebugFS acceso y ofrece los siguientes beneficios:

  • Evita la depuración de usuario construye a partir dependiendo accidentalmente DebugFS de nuevas funcionalidades
  • Garantiza que cualquier funcionalidad existente que se rompa por la falta de DebugFS se conozca al principio del ciclo de desarrollo.

Debugfs accesos en depuración de usuario compilaciones son categorizados de la siguiente manera:

  1. DebugFS inicializaciones de archivos durante el inicio del dispositivo, como un acceso de escritura a un archivo en DebugFS para activar la recolección de datos de depuración.
  2. La generación de informe de error: El HAL dumpstate lee DebugFS archivos cuando DumpstateBoard() es invocado por dumpstate . Esta información pasa a formar parte del informe de errores.
  3. Pruebas y validaciones específicas de dispositivos.

La tabla siguiente describe cómo cada una de estas tres categorías se admite en Android Android 11 y 12. Tenga en cuenta que la siguiente sólo se aplica a la depuración de usuario construye desde DebugFS no se pueden montar en el usuario construye.

Caso de uso Compilación de depuración de usuario de Android 11 Compilación de depuración de usuario de Android 12
De una sola vez DebugFS archivos de inicialización, durante el inicio. Este acceso ocurre sólo una vez durante el arranque. Vendor init hace esto. Dumpstate HAL realiza esto durante la inicialización de HAL. Para habilitar los mismos, init montajes DebugFS de depuración de usuario construye antes de que se inicie la HAL. Init llamadas umount() en DebugFS cuando el dispositivo ha terminado de arrancar.
La generación de informe de error: El HAL dumpstate lee DebugFS archivos, que se convierten en parte del informe de error. Hecho por HAL dumpstate dentro DumpstateBoard() cuando se invoca por la herramienta dumpstate. Hecho por HAL dumpstate dentro DumpstateBoard() cuando se invoca por dumpstate ( DumpstateDevice.cpp ). La herramienta dumpstate (parte del marco de Android) asegura que DebugFS montajes durante la invocación.
Pruebas y validaciones específicas de dispositivos Adb root y shell Adb root y shell. Mount DebugFS del adb shell con acceso root 1.

1 Para montar DebugFS de adb shell con acceso root, utilice este comando:

adb shell mount -t debugfs debugfs /sys/kernel/debug .

Acciones necesarias para socios

Los socios deben promulgar lo siguiente en función de estos cambios en los dispositivos con Android 12:

  • Hacen todas las inicializaciones de tiempo de arranque de DebugFS nodos ocurren durante la inicialización HAL dumpstate. Para un ejemplo de cómo hacerlo, consulte la DNM: Ejemplo para el momento del inicio de inicialización de DebugFS archivos .
  • No permita que DebugFS acceso en tiempo de ejecución. Se aplican las siguientes excepciones:
    • Generación de informes de errores (proviene de dumpstate HAL)
    • Prueba y validación (accesible por adb root y shell - garantizar que debugfs está montado primero)

Los desarrolladores pueden establecer la propiedad persistente de depuración persist.dbg.keep_debugfs_mounted para mantener DebugFs montados en los reinicios de depuración de usuario y construye esp.

GTS pruebas de cumplimiento aseguran que los DebugFS sistema de archivos no está montado en el usuario construye. Sepolicy neverallow declaraciones aseguran que en los dispositivos de lanzamiento en Android, 12 o procesos no autorizados superiores no se proporcionan acceso a DebugFs .