Partición de inicio genérica

En Android 12, la imagen boot genérica, denominada imagen genérica del kernel (GKI), contiene el disco RAM 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 de boot solo con el kernel de GKI.

Para los dispositivos que se actualizan y 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 solo contenga init de primera etapa y un archivo de propiedades que contenga información de la marca de tiempo.

En dispositivos que cumplen con las siguientes condiciones:

  • No se usa una partición recovery dedicada, 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 se necesita ningún cambio en el ramdisk recovery porque el ramdisk recovery es autónomo.

Arquitectura

En los siguientes diagramas, se ilustra la arquitectura para 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.

Lanzamiento con Android 13, sin recuperación dedicada

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

Figura 1: Dispositivos que se lanzan con Android 13 o se actualizan a esta versión, con GKI y sin recuperación dedicada.

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

Lanzamiento o actualización del dispositivo, 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 figura si el dispositivo tiene particiones recovery_a y recovery_b.

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

Lanzamiento o actualización del dispositivo, GKI, recuperación dedicada y no A/B

Figura 3: Dispositivos que se lanzan o 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.

Lanzamiento o actualización a Android 12, sin recuperación dedicada

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

Figura 4: Dispositivos que se lanzan con Android 12 o se actualizan a esa versión, con GKI y sin recuperación dedicada.

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

Lanzamiento o actualización del dispositivo, GKI, recuperación dedicada y A/B

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

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

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

Lanzamiento o actualización del dispositivo, GKI, recuperación dedicada y no A/B

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

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

Actualización a Android 12, recuperación como inicio (recuperación como ramdisk)

Lanzamiento o actualización del dispositivo, sin GKI, recuperación como arranque

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

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

Dispositivo de lanzamiento o actualización, sin GKI, recuperación dedicada

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

Contenido de imágenes de arranque

Las imágenes de arranque 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 certificado boot.img no está firmado para el inicio verificado. Los OEM deben seguir firmando el boot.img compilado previamente con una clave de AVB específica del dispositivo.
      • cmdline genérico (GENERIC_KERNEL_CMDLINE)
      • Kernel de GKI
    • Imagen de ramdisk genérica
      • Solo se incluye en las imágenes de boot de Android 12 y versiones anteriores.

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

    • vendor_boot encabezado
      • cmdline específico del dispositivo (BOARD_KERNEL_CMDLINE)
    • vendor_boot imagen de ramdisk
      • lib/modules
      • Recursos de recuperación (si no hay 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.
      • El DTBO se puede inferir del encabezado vendor_boot.
    • recovery imagen de ramdisk
      • Recursos de recuperación
      • En el caso de la partición de recuperación que no es 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 disco RAM de recuperación debe contener init.
      • En el caso de la partición de recuperación A/B, el ramdisk de recuperación se antepone al ramdisk genérico y vendor_boot, por lo que no es necesario que sea independiente. Por ejemplo:
      • lib/modules podría contener solo 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 vínculo simbólico en /init, pero se ve eclipsado por el objeto binario /init de la primera etapa en la imagen de inicio.

Contenido de imagen de ramdisk genérico

El disco RAM genérico contiene los siguientes componentes.

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

Integración de imágenes de arranque

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

  • TARGET_NO_KERNEL. Esta variable indica si la compilación usa una imagen de arranque compilada previamente. Si esta variable se establece en true, establece BOARD_PREBUILT_BOOTIMAGE en la ubicación de la imagen de arranque compilada previamente (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 el GKI. Esta variable no afecta a las propiedades del sistema ni a PRODUCT_PACKAGES.

    Este es el interruptor del GKI a nivel de la placa. Todas las siguientes variables están restringidas por esta variable.

  • 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 para vendor-ramdisk/ y no para recovery/root/.

    • Cuando está vacío, los recursos de recuperación se compilan solo para recovery/root/ y no para 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, ocurre lo siguiente:

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

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

    • Cuando está vacío, si BOARD_RECOVERY_AS_ROOT:

      • Si se configura, las claves AVB de la GSI se compilan en $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Si no se configura, las claves de AVB de la 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 lancen con Android 12 y usen la partición A/B recovery deben establecer esta variable en true. Los dispositivos que se lancen con Android 12 y usen una arquitectura que no sea A/B deben establecer esta variable en false para que la imagen de recuperación sea autónoma.

  • 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.

    • Otros 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 disco RAM genérico se agrega a init_boot.img en lugar de boot.img y requiere que las variables BOARD_AVB_INIT_BOOT* se configuren para vbmeta encadenado.

Combinaciones permitidas

Componente o variable Actualiza el dispositivo sin partición de recuperación Actualiza el dispositivo con la 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 Lanza el 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 vacío. Para estos dispositivos, si se configura BOARD_RECOVERYIMAGE_PARTITION_SIZE, se compila una imagen de recovery.

Habilita vbmeta encadenado para el inicio

Se debe habilitar 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 los dispositivos que usan GKI. En esos dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE debe estar vacío. El sistema como raíz tampoco se admite en 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 ello, 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 makefile instalen accidentalmente otros archivos en el disco RAM (en su lugar, mueve esos archivos a vendor_ramdisk).

Configurar dispositivos

Las instrucciones de configuración varían según 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, usan parámetros de configuración heredados y las nuevas variables de compilación deben estar vacías. En el caso de estos dispositivos, haz lo siguiente:

      • Establece BOARD_USES_RECOVERY_AS_BOOT en true. La arquitectura se muestra en la Figura 3.

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

    • Puede establecer BOARD_USES_RECOVERY_AS_BOOT como vacío. Si lo hacen, están usando configuraciones nuevas. Si se trata de dispositivos como los siguientes:

      • No uses una partición recovery dedicada. La arquitectura 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 se muestra en la figura 2a o la figura 2b, y la opción de configuración del dispositivo es Opción 2a o 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. En el caso de estos dispositivos, haz lo siguiente:

    • No uses una partición recovery dedicada. La arquitectura 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 se muestra en la figura 2a o la figura 2b, y la opción de configuración del dispositivo es Opción 2a o Opción 2b.

Como aosp_arm64 solo compila el GKI (y no vendor_boot ni la recuperación), no es un destino completo. Para 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 genérica boot en la partición boot. El disco RAM vendor_boot contiene todos los recursos de recuperación, incluido lib/modules (con módulos de kernel del proveedor). En estos 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 disco RAM vendor_boot puede contener un vínculo simbólico de /init a /system/bin/init y init_second_stage.recovery en /system/bin/init. Sin embargo, debido a que el disco RAM genérico se concatena después del disco RAM de vendor_boot, el vínculo simbólico /init se sobrescribe. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el objeto binario /system/bin/init para admitir la inicialización de segunda etapa. El contenido de vendor_boot y los ramdisks genéricos es el siguiente:

  • /init (desde 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 disco RAM genérico a vendor_ramdisk. Para ver un ejemplo, consulta este cambio.

Cómo instalar módulos

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

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

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

Consola de la primera etapa

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

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

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 la primera etapa (por ejemplo, adbd), usa el siguiente comando.

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 verificación de metadatos

Para admitir sumas de verificación de metadatos durante la activación en la primera etapa, los dispositivos que no admiten GKI instalan la variante de disco RAM 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 de A/B virtual, snapuserd debe instalarse 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 el modo de recuperación o en Android no cambia, con la siguiente excepción:

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

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

Cómo hacer que e2fsck esté disponible

Los archivos make del dispositivo pueden heredar de los siguientes archivos:

  • 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 de A/B

Usa esta opción para dispositivos con particiones A/B recovery, es decir, el dispositivo tiene una recovery_a y una recovery_b partition. Estos dispositivos incluyen los 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 disco RAM recovery contiene todos los recursos de recuperación. En estos dispositivos, la configuración del producto hereda de generic_ramdisk.mk.

Establece valores de BOARD

Establece los siguientes valores para los 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 disco RAM recovery puede contener un vínculo simbólico /init -> /system/bin/init y init_second_stage.recovery en /system/bin/init. Sin embargo, debido a que el disco RAM de arranque se concatena después del disco RAM de recovery, el vínculo simbólico de /init se sobrescribe. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el archivo binario /system/bin/init para admitir la inicialización de segunda etapa.

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

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

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

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

Cómo mover archivos fstab

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

Cómo instalar módulos

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

Consola de la primera etapa

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

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 la primera etapa (por ejemplo, adbd), habilita la variante vendor_ramdisk de estos módulos subiendo los parches pertinentes al 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 el disco RAM vendor_boot se carga en el modo de recuperación, el módulo también está disponible en recovery. Si el disco RAM vendor_boot no se carga en el modo de recuperación, el dispositivo también puede instalar adbd.recovery de forma opcional.

Sumas de verificación de metadatos

Para admitir sumas de verificación de metadatos durante la activación en la primera etapa, los dispositivos que no admiten GKI instalan la variante de disco RAM 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 arranque no cambia. El vendor_boot + ramdisk genérico es similar al proceso de arranque 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 el modo de recuperación, el proceso de inicio cambia. La recuperación + vendor_boot + disco RAM 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 cargador de arranque y, luego, se realiza lo siguiente:

    1. Envía la recuperación, vendor_boot y el disco RAM genérico a /. (Si el OEM duplica los módulos del 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 monta el disco RAM en / y, luego, ejecuta /init desde el disco RAM genérico.

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

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

Cómo hacer que e2fsck esté disponible

Los archivos make del dispositivo pueden heredar de los siguientes archivos:

  • 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 no 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 autónoma. 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 del kernel en lib/modules
  • Init de primera etapa como vínculo simbólico /init -> /system/bin/init
  • Objeto binario de init 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 estos dispositivos, la configuración del producto hereda de generic_ramdisk.mk.

Establece valores de BOARD

Establece los siguientes valores para los dispositivos que no son 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 disco RAM recovery debe contener un vínculo simbólico /init -> /system/bin/init y init_second_stage.recovery en /system/bin/init. Cuando el dispositivo se inicia en modo de recuperación, se necesita el archivo binario /system/bin/init para admitir la inicialización de primera y segunda etapa.

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

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

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

  • /init (desde ramdisk, compilado desde init_first_stage)

Cómo mover archivos fstab

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

Cómo instalar módulos

Puedes instalar módulos específicos del dispositivo en los discos RAM vendor_ramdisk y recovery (omite este paso si no tienes módulos específicos del dispositivo para instalar). init no cambia la 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 de cómo instalar módulos en los discos RAM vendor_ramdisk y recovery, consulta Consola de la primera etapa y Sumas de verificación de metadatos.

Consola de la primera etapa

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

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 la primera etapa (por ejemplo, adbd), habilita la variante vendor_ramdisk de estos módulos subiendo los parches pertinentes al 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 verificación de metadatos

Para admitir sumas de verificación de metadatos durante la activación en la primera etapa, los dispositivos que no admiten GKI instalan la variante de disco RAM 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 las sumas de verificación de metadatos durante el montaje de la primera etapa en la recuperación, habilita la variante de recuperación de estos módulos y también instálalos.

Cambios en el proceso de inicio

Cuando se inicia Android, el proceso de arranque no cambia. El vendor_boot + ramdisk genérico es similar al proceso de arranque 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 arranque no cambia. El disco RAM 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 cargador de arranque y, luego, se realiza lo siguiente:

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

  2. El kernel monta el ramdisk en / y, luego, ejecuta /init, que es un vínculo simbólico a /system/bin/init desde el ramdisk recovery.

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

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

Marcas de tiempo de la imagen de arranque

El siguiente código es un ejemplo de un archivo de marcas de tiempo de imágenes 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 momento de la compilación, se agrega un archivo system/etc/ramdisk/build.prop al disco RAM genérico. Este archivo contiene información de la marca de tiempo de la compilación.

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