Partición de arranque genérica

En Android 12, la imagen de boot genérica contiene el ramdisk de boot genérico y la imagen de kernel genérica (GKI) . 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 el inicio de la primera init y un archivo de propiedades que contenga información de marca de tiempo.

En dispositivos que:

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

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

Arquitectura

Los siguientes diagramas ilustran la arquitectura para dispositivos que ejecutan Android 12.

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

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

Figura 1. 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 2a. Dispositivos que se inician o actualizan a Android 12, con GKI, dedicado y recuperación A/B

Consulte esta figura si la recovery es A/B; es decir, 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 2b. Dispositivos que se inician o actualizan a Android 12, con GKI, recuperación dedicada y no A/B

Consulte esta figura si la recovery no es A/B; es decir, 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 3. 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 4. Dispositivos que se actualizan a Android 12, sin GKI, recuperación dedicada

Contenido de las imágenes de arranque

En Android 12, las imágenes de arranque contienen lo siguiente.

  • Imagen boot genérica
    • Versión de cabecera V3 o V4
      • Una firma de arranque para la certificación boot_signature boot.img (solo v4). El boot.img de GKI certificado no está firmado para un arranque verificado. Los OEM aún deben firmar el archivo boot.img con una clave AVB específica del dispositivo.
      • Línea GENERIC_KERNEL_CMDLINE cmdline
      • Imagen genérica del kernel
    • Imagen ramdisk boot genérica
  • imagen de vendor_boot (para obtener más información, consulte Particiones de arranque de proveedores )
    • encabezado vendor_boot
      • Línea de BOARD_KERNEL_CMDLINE 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
      • Línea de comandos específica del cmdline 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 del vendor_boot .
    • imagen de ramdisk de 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 de boot y del vendor_boot , por lo tanto, 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 del 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 de arranque

En Android 12, el ramdisk de boot 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 crean las imágenes de 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 de recovery como imagen de boot . Cuando se usa el 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 y una imagen boot genérica. 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 de recovery contiene un kernel o no. Los dispositivos que se inicien con Android 12 y usen la partición de 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.

Combinaciones permitidas

componente o variable Actualizar dispositivo sin partición de recovery Actualizar dispositivo con partición de recovery Iniciar dispositivo sin partición de recovery Iniciar dispositivo con partición de recovery A/B Iniciar dispositivo con partición de recovery no A/B aosp_arm64
Contiene boot sí sí 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_RESOURCE_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 de recovery dedicada pueden establecer PRODUCT_BUILD_RECOVERY_IMAGE en true o vacío. Para estos dispositivos, si se establece BOARD_RECOVERYIMAGE_PARTITION_SIZE , se genera una imagen de recovery .

Habilitar vbmeta encadenado para el arranque

El vbmeta encadenado debe estar habilitado para la imagen de 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

Para ver un ejemplo, consulte este cambio .

Sistema como root

El sistema como raíz no es compatible con dispositivos que usan GKI y la imagen de arranque genérica, independientemente de si el dispositivo es compatible con el módulo GKI actualizable. 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, lo cual es un requisito para usar el módulo GKI actualizable.

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 actualizan a Android 12 y los que se inician con 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:

      • No use una partición de 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 .

      • Utilice una partición de 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 inician con Android 12 deben configurar BOARD_USES_RECOVERY_AS_BOOT para vaciar y usar nuevas configuraciones. Si tales dispositivos:

    • No use una partición de 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 .

    • Utilice una partición de 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 crea solo la GKI y la imagen boot genérica (y no la recuperación o el arranque de vendor_boot ), no es un objetivo completo. Para las configuraciones de compilación de aosp_arm64 , consulte generic_arm64 .

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

Los dispositivos sin una partición de recovery contienen la imagen de boot genérica en la partición de boot . El ramdisk vendor_boot contiene todos los recursos de recuperación, incluidos lib/modules (con módulos de kernel de proveedor). En tales 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 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 de boot se concatena después del vendor_boot de arranque_proveedor, 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 + boot ramdisks es el siguiente:

  • /init (desde ramdisk, 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 de boot 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 de 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 de 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 de 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 \
    resizefs.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 vendor_ramdisk de snapuserd .

Cambios en el proceso de arranque

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

  • build.prop se mueve a /second_stage_resources para que el 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 de boot al vendor_boot de arranque_vendedor, el resultado de concatenar boot al vendor_boot de arranque_vendedor 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 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 de 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 vendor_boot del proveedor_arranque 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 proveedor)

El ramdisk de recovery contiene todos los recursos de recuperación. En tales 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 de 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 de 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 de 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 + boot ramdisks 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 + boot ramdisks es el siguiente:

  • /init (desde ramdisk, construido desde init_first_stage )

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el ramdisk de boot 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). 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 de 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 \
    resizefs.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 vendor_ramdisk de snapuserd .

Cambios en el proceso de arranque

Al arrancar en Android, el proceso de arranque no cambia. El ramdisk de boot + 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 ramdisk recovery + vendor_boot + boot es similar al proceso de recuperación existente, pero el kernel se carga desde la imagen de boot en lugar de desde la imagen de 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 + boot ramdisk 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 de boot .

  2. Kernel monta ramdisk en / luego ejecuta /init desde el ramdisk de boot .

  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 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 de 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 de 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 vendor_boot del proveedor_arranque 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 proveedor)

La imagen de 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 la 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 de recovery , etc.
  • etc.

En tales 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 de 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 la recovery , el contenido de los ramdisks de recovery es el siguiente:

  • /init -> /system/bin/init (desde el ramdisk de 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 + boot ramdisks es el siguiente:

  • /init (desde ramdisk, construido desde init_first_stage )

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el ramdisk de boot al ramdisk del vendor_ramdisk y al ramdisk de 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 de 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 de recovery de los módulos se instala en la raíz del ramdisk de 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 de 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 \
    resizefs.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 de boot + 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 de 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 de recovery .

  2. Kernel monta el ramdisk en / luego ejecuta /init , que es un enlace simbólico a /system/bin/init desde el ramdisk de 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 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 de recovery .

Marcas de tiempo de la imagen de arranque

El siguiente código es un archivo de marca de tiempo de imagen de 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 de imagen de boot genérico. Este archivo contiene información de marca de tiempo de la compilación.

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