Partición de inicio genérica

En Android 12, la imagen genérica boot, denominada imagen genérica del kernel (GKI), contiene el ramdisk genérico y el kernel de GKI.

En el caso de los dispositivos que se lanzan con Android 13, el ramdisk genérico se quita de la imagen boot y se coloca en una imagen init_boot separada. Este cambio deja la imagen boot solo con el kernel de GKI.

Para actualizar dispositivos que siguen usando Android 12 o versiones anteriores del kernel, el ramdisk genérico permanece donde estaba sin necesidad de una nueva imagen init_boot.

Para compilar un disco RAM genérico, quita los recursos específicos del proveedor del disco RAM de modo que el disco RAM genérico contenga solo init de primera etapa y un archivo de propiedades que contenga información de marca de tiempo.

En dispositivos con las siguientes características:

  • No uses una partición recovery dedicada, ya que todos los bits de recuperación se mueven del disco RAM genérico al disco RAM vendor_boot.

  • Usa una partición recovery dedicada. No es necesario realizar ningún cambio en el ramdisk recovery, ya que es independiente.recovery

Arquitectura

En los siguientes diagramas, se ilustra la arquitectura de los dispositivos que ejecutan Android 12 y versiones posteriores. Los dispositivos que se lanzan con Android 13 tienen una nueva imagen init_boot que contiene el ramdisk genérico. Los dispositivos que se actualizan de Android 12 a Android 13 usan la misma arquitectura que con Android 12.

Inicio con Android 13, sin recuperación dedicada

Inicio o actualización del dispositivo, GKI, sin recuperación dedicada

Figura 1: Dispositivos que se inician o se actualizan a Android 13, con GKI, sin recuperación dedicada

Se inicia con Android 13, recuperación A/B y dedicada (ramdisk dedicado)

Inicio o actualización de dispositivos, GKI, recuperación dedicada y A/B

Figura 2: Dispositivos que se lanzan o actualizan a Android 13, con GKI, recuperación dedicada y A/B

Consulta esta imagen si el dispositivo tiene particiones recovery_a y recovery_b.

Inicio con Android 13, recuperación dedicada y no A/B (ramdisk dedicado)

Inicio o actualización de dispositivos, GKI, recuperación dedicada y no A/B

Figura 3: Dispositivos que se inician o se actualizan a Android 13, con GKI, recuperación dedicada y no A/B.

Consulta esta figura si el dispositivo tiene una partición llamada recovery sin un sufijo de ranura.

Inicio o actualización a Android 12 sin recuperación dedicada

Inicio o actualización del dispositivo, GKI, sin recuperación dedicada

Figura 4: Dispositivos que se inician o se actualizan a Android 12, con GKI, sin recuperación dedicada

Inicio o actualización a Android 12, recuperación dedicada y A/B (ramdisk dedicado)

Inicio o actualización de dispositivos, GKI, recuperación dedicada y A/B

Figura 5: Dispositivos que se lanzan o actualizan a Android 12, con GKI, recuperación dedicada y A/B

Consulta esta imagen si el dispositivo tiene particiones recovery_a y recovery_b.

Inicio o actualización a Android 12, recuperación dedicada y no A/B (ramdisk dedicado)

Inicio o actualización de dispositivos, GKI, recuperación dedicada y no A/B

Figura 6: Dispositivos que se lanzan o actualizan a Android 12, con GKI, recuperación dedicada y no A/B

Consulta esta figura si el dispositivo tiene una partición llamada recovery sin un sufijo de ranura.

Actualización a Android 12, recovery-as-boot (recovery-as-ramdisk)

Inicio o actualización del dispositivo, sin GKI, recuperación como inicio

Figura 7: Dispositivos que se actualizan a Android 12, sin GKI, recuperación como inicio

Actualización a Android 12, recuperación dedicada (ramdisk dedicado)

Inicio o actualización del dispositivo, sin GKI, recuperación dedicada

Figura 8: Dispositivos que se actualizan a Android 12, sin GKI, recuperación dedicada

Contenido de las imágenes de arranque

Las imágenes de inicio de Android contienen lo siguiente:

  • Se agregó la imagen init_boot para los dispositivos que se lanzan con Android 13.

    • Versión del encabezado V4
    • Imagen genérica de ramdisk

  • Imagen genérica de boot

    • Versión del encabezado V3 o V4
      • Un boot_signature para la certificación de boot.img de GKI (solo v4) El GKI boot.img certificado no está firmado para el inicio verificado. Los OEMs aún deben firmar el boot.img precompilado con una clave AVB específica del dispositivo.
      • cmdline genérico (GENERIC_KERNEL_CMDLINE)
      • Kernel de GKI
    • Imagen genérica de ramdisk
      • Solo se incluye en las imágenes boot de Android 12 y versiones anteriores

  • Imagen vendor_boot (para obtener más información, consulta Particiones de inicio del proveedor)

    • Encabezado vendor_boot
      • cmdline específico del dispositivo (BOARD_KERNEL_CMDLINE)
    • Imagen de ramdisk vendor_boot
      • lib/modules
      • Recursos de recuperación (si no hay una recuperación dedicada)
    • dtb imagen

  • recovery imagen

    • Versión del encabezado V2
      • cmdline específico del dispositivo para la recuperación, si es necesario
      • En el caso de la partición de recuperación que no es A/B, el contenido del encabezado debe ser independiente. Consulta Imágenes de recuperación. Por ejemplo:
      • cmdline no se concatena con boot y vendor_boot cmdline.
      • El encabezado especifica el DTBO de recuperación, si es necesario.
      • En el caso de la partición de recuperación A/B, el contenido se puede concatenar o inferir a partir de boot y vendor_boot. Por ejemplo:
      • cmdline se concatena con boot y vendor_boot cmdline.
      • La DTBO se puede inferir del encabezado vendor_boot.
    • Imagen de ramdisk recovery
      • Recursos de recuperación
      • Para la partición de recuperación que no sea A/B, el contenido del ramdisk debe ser independiente. Consulta Imágenes de recuperación. Por ejemplo:
      • lib/modules debe contener todos los módulos de kernel necesarios para iniciar el modo de recuperación.
      • El ramdisk de recuperación debe contener init.
      • En el caso de la partición de recuperación A/B, el ramdisk de recuperación se agrega al genérico y al ramdisk de vendor_boot, por lo que no es necesario que sea independiente. Por ejemplo:
      • lib/modules puede contener solo los módulos de kernel adicionales necesarios para iniciar el modo de recuperación, además de los módulos de kernel en el ramdisk vendor_boot.
      • Es posible que exista el symlink en /init, pero está eclipsado por el objeto binario /init de primera etapa en la imagen de inicio.

Contenido de imagen genérica de ramdisk

El ramdisk genérico contiene los siguientes componentes.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build accesorios
  • Directorios vacíos para puntos de activación: debug_ramdisk/, mnt/, dev/, sys/, proc/ y metadata/
  • first_stage_ramdisk/
    • Directorios vacíos duplicados para puntos de activación: debug_ramdisk/, mnt/, dev/, sys/, proc/ y metadata/

Integración de imágenes de arranque

Las marcas de compilación controlan cómo se compilan las imágenes init_boot, boot, recovery y vendor_boot. El valor de una variable de tablero booleana debe ser la cadena true o estar vacía (que es la configuración predeterminada).

  • TARGET_NO_KERNEL. Esta variable indica si la compilación usa una imagen de inicio compilada previamente. Si esta variable se establece en true, establece BOARD_PREBUILT_BOOTIMAGE en la ubicación de la imagen de inicio precompilada (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

  • BOARD_USES_RECOVERY_AS_BOOT: Esta variable indica si el dispositivo usa la imagen recovery como la imagen boot. Cuando se usa GKI, esta variable está vacía y los recursos de recuperación se deben mover a vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Esta variable indica que la placa usa GKI. Esta variable no afecta a sysprops ni a PRODUCT_PACKAGES.

    Este es el interruptor GKI a nivel de la placa. Esta variable restringe todas las siguientes variables.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Esta variable controla si los recursos de recuperación de ramdisk se compilan en vendor_boot.

    • Cuando se establece en true, los recursos de recuperación se compilan solo en vendor-ramdisk/ y no en recovery/root/.

    • Cuando están vacíos, los recursos de recuperación se compilan solo en recovery/root/ y no en vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT: Esta variable controla si las claves de AVB de GSI se compilan en vendor_boot.

    • Cuando se establece en true, si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Si está establecido, las claves de AVB de GSI se compilan en $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • Si no se establece, las claves de AVB de GSI se compilan en $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Cuando está vacío, si BOARD_RECOVERY_AS_ROOT:

      • Si está establecido, las claves de AVB de GSI se compilan en $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Si no se establece, las claves de AVB de GSI se compilan en $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE: Esta variable controla si la imagen recovery contiene un kernel o no. Los dispositivos que se lanzan con Android 12 y usan la partición recovery de A/B deben establecer esta variable en true. Los dispositivos que se inician con Android 12 y que no usan A/B deben establecer esta variable en false para que la imagen de recuperación sea independiente.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Esta variable controla si $OUT/boot*.img se copia en IMAGES/ en los archivos de destino.

    • aosp_arm64 debe establecer esta variable en true.

    • Los demás dispositivos deben dejar esta variable vacía.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Esta variable controla si se genera init_boot.img y establece el tamaño. Cuando se configura, el ramdisk genérico se agrega a init_boot.img en lugar de boot.img y requiere que se configuren las variables BOARD_AVB_INIT_BOOT* para vbmeta encadenado.

Combinaciones permitidas

Componente o variable Cómo actualizar el dispositivo sin la partición de recuperación Actualiza el dispositivo con una partición de recuperación Cómo iniciar el dispositivo sin una partición de recuperación Cómo iniciar el dispositivo con la partición de recuperación A/B Cómo iniciar un dispositivo con una partición de recuperación que no sea A/B aosp_arm64
Contiene boot sí sí sí sí sí sí
Contiene init_boot (Android 13) no no sí sí sí sí
Contiene vendor_boot opcional opcional sí sí sí no
Contiene recovery no sí no sí sí no
BOARD_USES_RECOVERY_AS_BOOT true vacío vacío vacío vacío vacío
BOARD_USES_GENERIC_KERNEL_IMAGE vacío vacío true true true true
PRODUCT_BUILD_RECOVERY_IMAGE vacío true o vacío vacío true o vacío true o vacío vacío
BOARD_RECOVERYIMAGE_PARTITION_SIZE vacío > 0 vacío > 0 > 0 vacío
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT vacío vacío true vacío vacío vacío
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT vacío vacío true true true vacío
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE vacío vacío vacío true vacío vacío
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES vacío vacío vacío vacío vacío true

Los dispositivos con una partición recovery dedicada pueden establecer PRODUCT_BUILD_RECOVERY_IMAGE en true o dejarlo vacío. Para estos dispositivos, si se configura BOARD_RECOVERYIMAGE_PARTITION_SIZE, se compila una imagen recovery.

Habilita vbmeta encadenado para el inicio

Se debe habilitar el vbmeta encadenado para las imágenes boot y init_boot. Especifica lo siguiente:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

Para ver un ejemplo, consulta este cambio.

System-as-root

El sistema como raíz no es compatible con dispositivos que usan GKI. En esos dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE debe estar vacío. El sistema como raíz tampoco es compatible con dispositivos que usan particiones dinámicas.

Configuraciones de productos

Los dispositivos que usan el disco RAM genérico deben instalar una lista de archivos que se pueden instalar en el disco RAM. Para hacerlo, especifica lo siguiente en device.mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

El archivo generic_ramdisk.mk también evita que otros archivos de configuración de make instalen otros archivos en el ramdisk por accidente (en su lugar, mueve esos archivos a vendor_ramdisk).

Configurar dispositivos

Las instrucciones de configuración difieren entre los dispositivos que se lanzan con Android 13, los que se actualizan a Android 12 y los que se lanzan con Android 12. Android 13, se configuran de manera similar a como lo hacían con Android 12.

  • Dispositivos que se actualizan a Android 12:

    • Puede conservar el valor de BOARD_USES_RECOVERY_AS_BOOT. Si lo hacen, se están usando configuraciones heredadas, y las variables de compilación nuevas deben estar vacías. Si estos dispositivos cumplen con las siguientes características:

      • Si estableces BOARD_USES_RECOVERY_AS_BOOT en true, la arquitectura es como se muestra en la Figura 3.

      • Si estableces BOARD_USES_RECOVERY_AS_BOOT como vacío, la arquitectura es como se muestra en la Figura 4.

    • Se puede establecer BOARD_USES_RECOVERY_AS_BOOT como vacío. Si lo hacen, usarán configuraciones nuevas. Si los dispositivos cumplen con las siguientes condiciones:

      • No uses una partición recovery dedicada. La arquitectura es como se muestra en la Figura 1 y la opción de configuración del dispositivo es la Opción 1.

      • Usa una partición recovery dedicada. La arquitectura es como se muestra en la Figura 2a o la Figura 2b, y la opción de configuración del dispositivo es la Opción 2a o la Opción 2b.

  • Los dispositivos que se lanzan con Android 12 deben establecer BOARD_USES_RECOVERY_AS_BOOT como vacío y usar configuraciones nuevas. Si estos dispositivos cumplen con las siguientes características:

    • No uses una partición recovery dedicada. La arquitectura es como se muestra en la Figura 1 y la opción de configuración del dispositivo es la Opción 1.

    • Usa una partición recovery dedicada. La arquitectura es como se muestra en la Figura 2a o la Figura 2b, y la opción de configuración del dispositivo es la Opción 2a o la Opción 2b.

Debido a que aosp_arm64 solo compila GKI (y no vendor_boot ni recuperación), no es un destino completo. Para ver las configuraciones de compilación de aosp_arm64, consulta generic_arm64.

Opción 1: Sin partición de recuperación dedicada

Los dispositivos sin una partición recovery contienen la imagen boot genérica en la partición boot. El ramdisk vendor_boot contiene todos los recursos de recuperación, incluido lib/modules (con módulos de kernel del proveedor). En esos dispositivos, la configuración del producto hereda de generic_ramdisk.mk.

Establece valores de BOARD

Establece los siguientes valores:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

El ramdisk vendor_boot puede contener un symlink /init a /system/bin/init y init_second_stage.recovery en /system/bin/init. Sin embargo, como el ramdisk genérico se concatena después del ramdisk vendor_boot, se reemplaza el symlink /init. Cuando el dispositivo se inicia en modo de recuperación, se necesita el objeto binario /system/bin/init para admitir la inicialización de segundo nivel. El contenido de vendor_boot + ramdisks genéricos es el siguiente:

  • /init (desde el ramdisk genérico, compilado desde init_first_stage)
  • /system/bin/init (de vendor_ramdisk, compilado a partir de init_second_stage.recovery)

Cómo mover archivos fstab

Mueve los archivos fstab que se instalaron en el ramdisk genérico a vendor_ramdisk. Para ver un ejemplo, consulta este cambio.

Instala módulos

Puedes instalar módulos específicos del dispositivo en vendor_ramdisk (omite este paso si no tienes ningún módulo específico del dispositivo para instalar).

  • Usa la variante vendor_ramdisk del módulo cuando este se instale en /first_stage_ramdisk. Este módulo debería estar disponible después de que init cambie el permiso de administrador a /first_stage_ramdisk, pero antes de que init cambie el permiso de administrador a /system. Para ver ejemplos, consulta Suma de comprobación de metadatos y Compresión A/B virtual.

  • Usa la variante recovery del módulo cuando este se instale en /. Este módulo debería estar disponible antes de que init cambie el estado de raíz a /first_stage_ramdisk. Para obtener detalles sobre cómo instalar módulos en /, consulta Consola de primera etapa.

Consola de la primera etapa

Debido a que la consola de la primera etapa se inicia antes de que init cambie el estado de raíz a /first_stage_ramdisk, debes instalar la variante recovery de los módulos. De forma predeterminada, ambas variantes de módulo se instalan en build/make/target/product/base_vendor.mk, por lo que, si el archivo de configuración del dispositivo hereda de ese archivo, no es necesario instalar explícitamente la variante recovery.

Para instalar los módulos de recuperación de forma explícita, usa lo siguiente.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Esto garantiza que linker, sh y toybox se instalen en $ANDROID_PRODUCT_OUT/recovery/root/system/bin, que luego se instala en /system/bin en vendor_ramdisk.

Para agregar los módulos necesarios para la consola de primera etapa (por ejemplo, adbd), usa lo siguiente.

PRODUCT_PACKAGES += adbd.recovery

Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/recovery/root/system/bin, que luego se instala en /system/bin en vendor_ramdisk.

Sumas de comprobación de metadatos

Para admitir sumas de comprobación de metadatos durante la activación de la primera etapa, los dispositivos que no admiten GKI instalan la variante de ramdisk de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para ver un ejemplo, consulta esta lista de cambios.

Compresión de A/B virtual

Para admitir la compresión A/B virtual, se debe instalar snapuserd en vendor_ramdisk. El dispositivo debe heredar de virtual_ab_ota/compression.mk, que instala la variante vendor_ramdisk de snapuserd.

Cambios en el proceso de inicio

El proceso de inicio en modo de recuperación o en Android no cambia, con la siguiente excepción:

  • El build.prop de Ramdisk se mueve a /second_stage_resources para que el init de la segunda etapa pueda leer la marca de tiempo de compilación del inicio.

Debido a que los recursos se mueven del disco RAM genérico al disco RAM vendor_boot, el resultado de concatenar el disco RAM genérico al disco RAM vendor_boot no cambia.

Cómo hacer que e2fsck esté disponible

Los archivos de configuración de make del dispositivo pueden heredar lo siguiente:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si el dispositivo admite A/B virtual, pero no compresión.

  • virtual_ab_ota/compression.mk si el dispositivo admite la compresión A/B virtual.

Los archivos makefile del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. En el tiempo de ejecución, la primera etapa init cambia la raíz a /first_stage_ramdisk y, luego, ejecuta /system/bin/e2fsck.

Opción 2a: Partición de recuperación dedicada y A/B

Usa esta opción para dispositivos con particiones recovery A/B, es decir, el dispositivo tiene un recovery_a y un recovery_b partition. Estos dispositivos incluyen dispositivos A/B y A/B virtuales cuya partición de recuperación se puede actualizar, con la siguiente configuración:

AB_OTA_PARTITIONS += recovery

El ramdisk vendor_boot contiene los bits del proveedor del ramdisk y los módulos del kernel del proveedor, incluidos los siguientes:

  • Archivos fstab específicos del dispositivo

  • lib/modules (incluye módulos de kernel del proveedor)

El ramdisk recovery contiene todos los recursos de recuperación. En esos dispositivos, la configuración del producto hereda de generic_ramdisk.mk.

Establece valores de BOARD

Establece los siguientes valores para dispositivos con partición recovery A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

El ramdisk recovery puede contener un symlink /init -> /system/bin/init y init_second_stage.recovery en /system/bin/init. Sin embargo, como el ramdisk de inicio se concatena después del ramdisk de recovery, se reemplaza el symlink de /init. Cuando el dispositivo se inicia en modo de recuperación, se necesita el objeto binario /system/bin/init para admitir la inicialización de segundo nivel.

Cuando el dispositivo se inicia en recovery, el contenido de recovery + vendor_boot + ramdisks genéricos es el siguiente:

  • /init (desde el ramdisk, compilado desde init_first_stage)
  • /system/bin/init (desde el ramdisk recovery, compilado desde init_second_stage.recovery y ejecutado desde /init)

Cuando el dispositivo se inicia en Android, el contenido de vendor_boot + ramdisks genéricos es el siguiente:

  • /init (desde el ramdisk genérico, compilado desde init_first_stage)

Cómo mover archivos fstab

Mueve los archivos fstab que se instalaron en el ramdisk genérico a vendor_ramdisk. Para ver un ejemplo, consulta este cambio.

Instala módulos

De manera opcional, puedes instalar módulos específicos del dispositivo en vendor_ramdisk (omite este paso si no tienes ningún módulo específico del dispositivo para instalar). Init no cambia de raíz. La variante vendor_ramdisk de los módulos se instala en la raíz de vendor_ramdisk. Para ver ejemplos sobre la instalación de módulos en vendor_ramdisk, consulta Consola de primera etapa, Suma de comprobación de metadatos y Compresión A/B virtual.

Consola de la primera etapa

Para instalar la variante vendor_ramdisk de los módulos, usa lo siguiente:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Esto garantiza que linker, sh y toybox se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, que luego se instala en /system/bin en vendor_ramdisk.

Para agregar los módulos necesarios para la consola de primera etapa (por ejemplo, adbd), habilita la variante vendor_ramdisk de estos módulos subiendo los parches relevantes a AOSP y, luego, usa lo siguiente:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Si se carga el ramdisk vendor_boot en el modo de recuperación, el módulo también está disponible en recovery. Si el ramdisk vendor_boot no se carga en el modo de recuperación, el dispositivo también puede instalar adbd.recovery de forma opcional.

Sumas de comprobación de metadatos

Para admitir sumas de comprobación de metadatos durante la activación de la primera etapa, los dispositivos que no admiten GKI instalan la variante de ramdisk de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para ver un ejemplo, consulta esta lista de cambios.

Compresión de A/B virtual

Para admitir la compresión de A/B virtual, se debe instalar snapuserd en vendor_ramdisk. El dispositivo debe heredar de virtual_ab_ota/compression.mk, que instala la variante vendor_ramdisk de snapuserd.

Cambios en el proceso de inicio

Cuando se inicia Android, el proceso de inicio no cambia. El vendor_boot + ramdisk genérico es similar al proceso de inicio existente, excepto que fstab se carga desde vendor_boot. Como system/bin/recovery no existe, first_stage_init lo controla como un inicio normal.

Cuando se inicia el modo de recuperación, el proceso de inicio cambia. La recuperación + vendor_boot + ramdisk genérico es similar al proceso de recuperación existente, pero el kernel se carga desde la imagen boot en lugar de la imagen recovery. El proceso de inicio del modo de recuperación es el siguiente:

  1. Se inicia el bootloader y, luego, realiza lo siguiente:

    1. Envía la recuperación + vendor_boot + ramdisk genérico a /. (Si el OEM duplica los módulos de kernel en el disco RAM de recuperación agregándolos a BOARD_RECOVERY_KERNEL_MODULES, vendor_boot es opcional).
    2. Ejecuta el kernel desde la partición boot.

  2. El kernel activa el ramdisk en / y, luego, ejecuta /init desde el ramdisk genérico.

  3. Se inicia la inicialización de la primera etapa y, luego, se hace lo siguiente:

    1. Establece IsRecoveryMode() == true y ForceNormalBoot() == false.
    2. Carga módulos de kernel del proveedor desde /lib/modules.
    3. Llama a DoFirstStageMount(), pero omite el activador porque IsRecoveryMode() == true. (El dispositivo no libera el ramdisk (porque / sigue siendo el mismo), pero llama a SetInitAvbVersionInRecovery()).
    4. Inicia la inicialización de la segunda etapa desde /system/bin/init desde el ramdisk recovery.

Cómo hacer que e2fsck esté disponible

Los archivos de configuración de make del dispositivo pueden heredar lo siguiente:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk si el dispositivo admite A/B virtual, pero no compresión.

  • virtual_ab_ota/compression.mk si el dispositivo admite la compresión A/B virtual.

Los archivos makefile del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. En el tiempo de ejecución, la primera etapa init ejecuta /system/bin/e2fsck.

Opción 2b: Partición de recuperación dedicada y no A/B

Usa esta opción para dispositivos con una partición recovery que no sea A/B, es decir, el dispositivo tiene una partición llamada recovery sin un sufijo de ranura. Entre estos dispositivos, se incluyen los siguientes:

  • dispositivos que no son A/B
  • Dispositivos A/B y A/B virtuales, cuya partición de recuperación no se puede actualizar (este no es un caso común).

El ramdisk vendor_boot contiene los bits del proveedor del ramdisk y los módulos del kernel del proveedor, incluidos los siguientes:

  • Archivos fstab específicos del dispositivo
  • lib/modules (incluye módulos de kernel del proveedor)

La imagen recovery debe ser independiente. Debe contener todos los recursos necesarios para iniciar el modo de recuperación, incluidos los siguientes:

  • La imagen del kernel
  • La imagen de DTBO
  • Módulos de kernel en lib/modules
  • Inicio de la primera etapa como symlink /init -> /system/bin/init
  • Objeto binario de inicio de segunda etapa /system/bin/init
  • Archivos fstab específicos del dispositivo
  • Todos los demás recursos de recuperación, incluido el binario recovery

En esos dispositivos, la configuración del producto hereda de generic_ramdisk.mk.

Establece valores de BOARD

Establece los siguientes valores para dispositivos que no sean A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

El ramdisk recovery debe contener un symlink /init -> /system/bin/init y init_second_stage.recovery en /system/bin/init. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el binario /system/bin/init para admitir la inicialización de la primera y la segunda etapa.

Cuando el dispositivo se inicia en recovery, el contenido de los ramdisks de recovery es el siguiente:

  • /init -> /system/bin/init (de recovery ramdisk)
  • /system/bin/init (desde el ramdisk recovery, compilado desde init_second_stage.recovery y ejecutado desde /init)

Cuando el dispositivo se inicia en Android, el contenido de vendor_boot + ramdisks genéricos es el siguiente:

  • /init (desde el ramdisk, compilado desde init_first_stage)

Cómo mover archivos fstab

Mueve los archivos fstab que se instalaron en el disco RAM genérico al disco RAM vendor_ramdisk y recovery. Para ver un ejemplo, consulta este cambio.

Instala módulos

Puedes instalar módulos específicos del dispositivo en el ramdisk vendor_ramdisk y recovery (omite este paso si no tienes ningún módulo específico del dispositivo para instalar). init no cambia de raíz. La variante vendor_ramdisk de los módulos se instala en la raíz de vendor_ramdisk. La variante recovery de los módulos se instala en la raíz del disco RAM recovery. Para ver ejemplos sobre la instalación de módulos en el disco RAM vendor_ramdisk y recovery, consulta Consola de primera etapa y Suma de comprobación de metadatos.

Consola de la primera etapa

Para instalar la variante vendor_ramdisk de los módulos, usa lo siguiente:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Esto garantiza que linker, sh y toybox se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, que luego se instala en /system/bin en vendor_ramdisk.

Para agregar los módulos necesarios para la consola de primera etapa (por ejemplo, adbd), habilita la variante vendor_ramdisk de estos módulos subiendo los parches relevantes a AOSP y, luego, usa lo siguiente:

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

Para instalar la variante recovery de los módulos, reemplaza vendor_ramdisk por recovery:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Sumas de comprobación de metadatos

Para admitir sumas de comprobación de metadatos durante la activación de la primera etapa, los dispositivos que no admiten GKI instalan la variante de ramdisk de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para admitir sumas de comprobación de metadatos durante la activación de la primera etapa en la recuperación, habilita la variante de recuperación de estos módulos y también instálala.

Cambios en el proceso de inicio

Cuando se inicia Android, el proceso de inicio no cambia. El vendor_boot + ramdisk genérico es similar al proceso de inicio existente, excepto que fstab se carga desde vendor_boot. Como system/bin/recovery no existe, first_stage_init lo controla como un inicio normal.

Cuando se inicia en modo de recuperación, el proceso de inicio no cambia. El ramdisk de recuperación se carga de la misma manera que el proceso de recuperación existente. El kernel se carga desde la imagen recovery. El proceso de inicio del modo de recuperación es el siguiente:

  1. Se inicia el bootloader y, luego, realiza lo siguiente:

    1. Envía el ramdisk de recuperación a /.
    2. Ejecuta el kernel desde la partición recovery.

  2. El kernel activa el ramdisk en / y, luego, ejecuta /init, que es un symlink a /system/bin/init desde el ramdisk recovery.

  3. Se inicia la inicialización de la primera etapa y, luego, se hace lo siguiente:

    1. Establece IsRecoveryMode() == true y ForceNormalBoot() == false.
    2. Carga módulos de kernel del proveedor desde /lib/modules.
    3. Llama a DoFirstStageMount(), pero omite el activador porque IsRecoveryMode() == true. (El dispositivo no libera el ramdisk (porque / sigue siendo el mismo), pero llama a SetInitAvbVersionInRecovery()).
    4. Inicia la inicialización de la segunda etapa desde /system/bin/init desde el ramdisk recovery.

Marcas de tiempo de la imagen de arranque

El siguiente código es un ejemplo de archivo de marca de tiempo de imagen boot:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • En el tiempo de compilación, se agrega un archivo system/etc/ramdisk/build.prop al ramdisk genérico. Este archivo contiene información de la marca de tiempo de la compilación.

  • Durante el tiempo de ejecución, el init de la primera etapa copia archivos del disco RAM a tmpfs antes de liberarlo para que el init de la segunda etapa pueda leer este archivo y establecer las propiedades de marca de tiempo de la imagen boot.