Partición de arranque genérica

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

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

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

Para crear un ramdisk genérico, mueva los recursos específicos del proveedor fuera del ramdisk de modo que el ramdisk genérico contenga solo init de la primera etapa y un archivo de propiedades que contenga información de marca de tiempo.

En dispositivos que:

  • No use una partición recovery dedicada, todos los bits de recuperación se mueven del ramdisk genérico al ramdisk vendor_boot .

  • Utilice una partición recovery dedicada, no se necesita ningún cambio en el ramdisk recovery porque el ramdisk recovery es autónomo.

Arquitectura

Los siguientes diagramas ilustran la arquitectura para dispositivos que ejecutan Android 12 y superior. El dispositivo que se inicia con Android 13 tiene 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

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

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

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

Dispositivo de lanzamiento/actualización, GKI, dedicado y recuperación A/B

Figura 2. Dispositivos que se inician o actualizan a Android 13, con GKI, dedicado y recuperación A/B

Consulte 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)

Dispositivo de lanzamiento/actualización, GKI, recuperación dedicada y no A/B

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

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

Inicie o actualice a Android 12, sin recuperación dedicada

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

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

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

Dispositivo de lanzamiento/actualización, GKI, dedicado y recuperación A/B

Figura 5. Dispositivos que se inician o actualizan a Android 12, con GKI, dedicado y recuperación A/B

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

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

Dispositivo de lanzamiento/actualización, GKI, recuperación dedicada y no A/B

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

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

Actualice a Android 12, recuperación como arranque (recuperación como ramdisk)

Iniciar/actualizar dispositivo, sin GKI, recuperación como arranque

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

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

Dispositivo de lanzamiento/actualización, 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 arranque de Android contienen lo siguiente.

  • Imagen init_boot agregada para dispositivos que se inician con Android 13

    • Cabecera versión V4
    • Imagen ramdisk genérica

  • Imagen boot genérica

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

  • imagen vendor_boot (para obtener más información, consulte Particiones de arranque de proveedores )

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

  • imagen recovery

    • Versión de encabezado V2
      • cmdline específica del dispositivo para la recuperación, si es necesario
      • Para la partición de recuperación que no es A/B, el contenido del encabezado debe ser independiente; consulte Imágenes de recuperación . Por ejemplo:
      • cmdline no está concatenado con boot y vendor_boot cmdline .
      • El encabezado especifica el DTBO de recuperación, si es necesario.
      • Para la partición de recuperación A/B, el contenido se puede concatenar o deducir de boot y vendor_boot . Por ejemplo:
      • cmdline se concatena con boot y vendor_boot cmdline .
      • 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 es A/B, el contenido del ramdisk debe ser independiente; consulte Imágenes de recuperación . Por ejemplo:
      • lib/modules debe contener todos los módulos del núcleo necesarios para iniciar el modo de recuperación
      • El ramdisk de recuperación debe contener init .
      • Para 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 pueden 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 .
      • El enlace simbólico en /init puede existir, pero está eclipsado por el binario /init de la primera etapa en la imagen de arranque.

Contenido genérico de la imagen ramdisk

El ramdisk genérico contiene los siguientes componentes.

  • init
  • Añadido system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build
  • Directorios vacíos para puntos de montaje: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
  • first_stage_ramdisk/
    • Directorios vacíos duplicados para puntos de montaje: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

Integración de imagen de arranque

Los indicadores 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 el valor predeterminado).

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

  • BOARD_USES_RECOVERY_AS_BOOT . Esta variable indica si el dispositivo utiliza la imagen recovery como imagen de 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 conmutador GKI a nivel de placa; todas las variables enumeradas a continuación están restringidas por esta variable.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . Esta variable controla si los recursos de recuperación de ramdisk están integrados en vendor_boot .

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

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

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . Esta variable controla si las claves GSI AVB se construyen para vendor_boot .

    • Cuando se establece en true , si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • está configurado, las claves GSI AVB se crean en $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb .

      • No está configurado, las claves GSI AVB están integradas en $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb .

    • Cuando está vacío, si BOARD_RECOVERY_AS_ROOT :

      • está configurado, las claves GSI AVB están integradas en $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb .

      • No está configurado, las claves GSI AVB están integradas 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 inicien con Android 12 y usen la partición recovery A/B deben establecer esta variable en true . Los dispositivos que se inician con Android 12 y no usan A/B deben establecer esta variable en false para mantener la imagen de recuperación 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 .

    • 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 ramdisk 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 Actualizar dispositivo sin partición recovery Actualizar dispositivo con partición recovery Iniciar dispositivo sin partición recovery Iniciar dispositivo con partición recovery A/B Iniciar dispositivo con partición recovery no 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 establece BOARD_RECOVERYIMAGE_PARTITION_SIZE , se crea una imagen recovery .

Habilitar vbmeta encadenado para el arranque

El vbmeta encadenado debe estar habilitado para las imágenes boot e init_boot . Especifique 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, consulte este cambio .

Sistema como root

System-as-root no es compatible con dispositivos que usan GKI. En dichos dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE debe estar vacío. System-as-root tampoco es compatible con dispositivos que usan particiones dinámicas.

Configuraciones de productos

Los dispositivos que utilizan el ramdisk genérico deben instalar una lista de archivos que pueden instalarse en el ramdisk. Para hacerlo, especifique 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 MAKE instalen accidentalmente otros archivos en el ramdisk (en su lugar, mueva dichos archivos a vendor_ramdisk ).

Configuración de dispositivos

Las instrucciones de configuración difieren entre los dispositivos que se inician con Android 13, se actualizan a Android 12 y se inician con Android 12. La configuración de Android 13 es similar a la de Android 12

  • Dispositivos que se actualizan a Android 12:

    • Puede conservar el valor de BOARD_USES_RECOVERY_AS_BOOT . Si lo hacen, están usando configuraciones heredadas y las nuevas variables de compilación deben estar vacías. Si tales dispositivos:

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

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

    • Puede configurar BOARD_USES_RECOVERY_AS_BOOT para que esté vacío. Si lo hacen, están usando nuevas configuraciones. Si tales dispositivos:

  • Los dispositivos que se inician con Android 12 deben configurar BOARD_USES_RECOVERY_AS_BOOT para vaciar y usar nuevas configuraciones. Si tales dispositivos:

Debido a que aosp_arm64 compila solo GKI (y no vendor_boot o recovery), no es un objetivo completo. Para las configuraciones de compilación aosp_arm64 , consulte 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, incluidos lib/modules (con módulos de kernel de proveedor). En dichos dispositivos, la configuración del producto se hereda de generic_ramdisk.mk .

Configuración de los valores de la TARJETA

Establezca 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 enlace simbólico /init a /system/bin/init e init_second_stage.recovery en /system/bin/init . Sin embargo, debido a que el ramdisk genérico se concatena después del ramdisk vendor_boot , el enlace simbólico /init se sobrescribe. Cuando el dispositivo inicia la recuperación, se necesita el binario /system/bin/init para admitir el inicio de la segunda etapa. El contenido de vendor_boot + ramdisks genéricos es el siguiente:

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

Mover archivos fstab

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

Instalación de módulos

Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk (omita este paso si no tiene ningún módulo específico del dispositivo para instalar).

  • Utilice la variante vendor_ramdisk del módulo cuando el módulo se instala en /first_stage_ramdisk . Este módulo debería 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, consulte Sumas de verificación de metadatos y compresión A/B virtual .

  • Utilice la variante recovery del módulo cuando el módulo se instale en / . Este módulo debería 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 / , consulte Consola de primera etapa .

consola primera etapa

Debido a que la consola de la primera etapa se inicia antes de que init cambie la raíz a /first_stage_ramdisk , debe instalar la variante de recovery de los módulos. De manera 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 se hereda de ese archivo, no necesita instalar explícitamente la variante recovery .

Para instalar explícitamente los módulos de recuperación, use lo siguiente.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

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

Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), use 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 debajo de vendor_ramdisk .

Sumas de verificación de metadatos

Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva 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, consulte esta lista de cambios .

Compresión virtual A/B

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 de snapuserd de vendor_ramdisk .

Cambios en el proceso de arranque

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

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

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

Hacer que e2fsck esté disponible

Los archivos MAKE del dispositivo pueden heredar de:

  • 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 es compatible con la compresión A/B virtual.

Los archivos MAKE del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . En tiempo de ejecución, el init de la primera etapa 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

Use esta opción para dispositivos con particiones recovery A/B; es decir, el dispositivo tiene una recovery_b partition recovery_a y recovery_b. Tales dispositivos incluyen dispositivos A/B y Virtual A/B cuya partición de recuperación es actualizable, con la siguiente configuración:

AB_OTA_PARTITIONS += recovery

El ramdisk del 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 de proveedores)

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

Configuración de los valores de la TARJETA

Establezca 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 enlace simbólico /init -> /system/bin/init e init_second_stage.recovery en /system/bin/init . Sin embargo, debido a que el ramdisk de arranque se concatena después del ramdisk recovery , el enlace simbólico /init se sobrescribe. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el binario /system/bin/init para admitir el inicio de la segunda etapa.

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

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

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

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

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el disco RAM genérico al disco ramdisk del vendor_ramdisk . Para ver un ejemplo, consulte este cambio .

Instalación de módulos

Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk (omita este paso si no tiene ningún módulo específico del dispositivo para instalar). Init no cambia de raíz. La variante de módulos vendor_ramdisk se instala en la raíz de vendor_ramdisk . Para ver ejemplos sobre cómo instalar módulos en vendor_ramdisk , consulte Consola de primera etapa , sumas de verificación de metadatos y compresión A/B virtual .

consola primera etapa

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), habilite la variante de estos módulos de vendor_ramdisk cargando los parches relevantes en AOSP, luego use 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 ramdisk vendor_boot se carga en modo de recuperación, el módulo también está disponible en recovery . Si el ramdisk vendor_boot no está cargado en modo de recuperación, el dispositivo también puede instalar opcionalmente adbd.recovery .

Sumas de verificación de metadatos

Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva 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, consulte esta lista de cambios .

Compresión virtual A/B

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

Cambios en el proceso de arranque

Al arrancar en Android, el proceso de arranque no cambia. El ramdisk genérico vendor_boot + es similar al proceso de arranque existente, excepto que fstab se carga desde vendor_boot . Debido a que system/bin/recovery no existe, first_stage_init lo maneja como un arranque normal.

Al iniciar en modo de recuperación, el proceso de inicio cambia. El disco de recuperación + vendor_boot + ramdisk genérico es similar al proceso de recuperación existente, pero el núcleo se carga desde la imagen boot en lugar de desde la imagen recovery . El proceso de arranque para el modo de recuperación es el siguiente.

  1. El cargador de arranque se inicia, luego hace lo siguiente:

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

  2. Kernel monta ramdisk en / luego ejecuta /init desde el ramdisk genérico.

  3. Inicia la primera etapa, luego hace lo siguiente:

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

Hacer que e2fsck esté disponible

Los archivos MAKE del dispositivo pueden heredar de:

  • 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 es compatible con la compresión A/B virtual.

Los archivos MAKE del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck . En 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

Utilice esta opción para dispositivos con una partición recovery que no sea A/B; es decir, el dispositivo tiene una partición denominada recovery sin un sufijo de ranura. Tales dispositivos incluyen:

  • dispositivos no A/B;
  • Dispositivos A/B y Virtual A/B, de los cuales la partición de recuperación no es actualizable. (Esto es inusual).

El ramdisk del 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 de proveedores)

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

  • La imagen del núcleo
  • La imagen DTBO
  • Módulos del kernel en lib/modules
  • Inicialización de primera etapa como enlace simbólico /init -> /system/bin/init
  • 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 , etc.
  • etc.

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

Configuración de los valores de la TARJETA

Establezca 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 enlace simbólico /init -> /system/bin/init e 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 el inicio de la primera y la segunda etapa.

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

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

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

  • /init (desde ramdisk, construido desde init_first_stage )

Mover archivos fstab

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

Instalación de módulos

Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk y ramdisk recovery (omita este paso si no tiene ningún módulo específico del dispositivo para instalar). init no cambia de raíz. La variante de módulos vendor_ramdisk se instala en la raíz de vendor_ramdisk . La variante recovery de los módulos se instala en la raíz del ramdisk recovery . Para ver ejemplos sobre la instalación de módulos en vendor_ramdisk y recovery ramdisk, consulte Consola de primera etapa y sumas de verificación de metadatos .

consola primera etapa

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), habilite la variante de estos módulos de vendor_ramdisk cargando los parches relevantes en AOSP, luego use 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, reemplace vendor_ramdisk con 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 el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva 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 verificación de metadatos durante el montaje de la primera etapa en la recuperación, habilite la variante de recuperación de estos módulos e instálelos también.

Cambios en el proceso de arranque

Al arrancar en Android, el proceso de arranque no cambia. El ramdisk genérico vendor_boot + es similar al proceso de arranque existente, excepto que fstab se carga desde vendor_boot . Debido a que system/bin/recovery no existe, first_stage_init lo maneja como un arranque normal.

Al iniciar 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 arranque para el modo de recuperación es el siguiente.

  1. El cargador de arranque se inicia, luego hace lo siguiente:

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

  2. Kernel monta el ramdisk en / luego ejecuta /init , que es un enlace simbólico a /system/bin/init desde el ramdisk recovery .

  3. Inicia la primera etapa, luego hace lo siguiente:

    1. Establece IsRecoveryMode() == true y ForceNormalBoot() == false .
    2. Carga los módulos del kernel del proveedor desde /lib/modules .
    3. Llama a DoFirstStageMount() pero omite el montaje porque IsRecoveryMode() == true . (El dispositivo no libera ramdisk (porque / sigue siendo el mismo) pero llama a SetInitAvbVersionInRecovery() ).
    4. Inicia el inicio 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 archivo de marca de tiempo de imagen boot de ejemplo.

####################################
# 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 ramdisk genérico. Este archivo contiene información de marca de tiempo de la compilación.

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