Partición de arranque genérica

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

Para los dispositivos que se inician con Android 13, el disco RAM 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 disco ram genérico permanece donde estaba sin necesidad de una nueva imagen init_boot .

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

En dispositivos que:

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

  • Utilice una partición recovery dedicada; no es necesario realizar ningún cambio en el disco ram recovery porque el disco ram recovery es autónomo.

Arquitectura

Los siguientes diagramas ilustran la arquitectura para dispositivos con Android 12 y versiones posteriores. El dispositivo que se inicia con Android 13 tiene una nueva imagen init_boot que contiene el disco ram genérico. Los dispositivos que se actualizan de Android 12 a Android 13 utilizan la misma arquitectura que con Android 12.

Lanzamiento con Android 13, sin recuperación dedicada

Lanzar/actualizar dispositivo, GKI, sin recuperación dedicada

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

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

Lanzar/actualizar dispositivo, GKI, recuperación dedicada y A/B

Figura 2. Dispositivos que inician o actualizan a Android 13, con GKI, recuperación dedicada y 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 (disco ram dedicado)

Lanzar/actualizar dispositivo, GKI, recuperación dedicada y no A/B

Figura 3. Dispositivos que 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 llamada recovery sin un sufijo de ranura.

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

Lanzar/actualizar dispositivo, GKI, sin recuperación dedicada

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

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

Lanzar/actualizar dispositivo, GKI, recuperación dedicada y A/B

Figura 5. Dispositivos que inician o actualizan a Android 12, con GKI, recuperación dedicada y 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 (disco ram dedicado)

Lanzar/actualizar dispositivo, GKI, recuperación dedicada y no A/B

Figura 6. Dispositivos que 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 llamada recovery sin un sufijo de ranura.

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

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 (disco ram dedicado)

Lanzar/actualizar dispositivo, sin GKI, recuperación dedicada

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

Contenido de las imágenes de arranque

Las imágenes de arranque de Android contienen lo siguiente.

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

    • Versión de encabezado V4
    • Imagen genérica de disco ram

  • Imagen boot genérica

    • Versión de encabezado V3 o V4
      • Una boot_signature para la certificación GKI boot.img (solo v4). El archivo GKI boot.img certificado no está firmado para el inicio verificado. Los OEM aún deben firmar el boot.img prediseñado con una clave AVB específica del dispositivo.
      • cmdline genérica ( GENERIC_KERNEL_CMDLINE )
      • Núcleo GKI
    • Imagen genérica de disco ram
      • Solo incluido en imágenes boot de Android 12 y versiones anteriores

  • imagen vendor_boot (para más detalles, consulte Particiones de arranque del proveedor )

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

  • imagen recovery

    • Versión de encabezado V2
      • cmdline específica del dispositivo para recuperación, si es necesario
      • Para particiones de recuperación que no sean 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 la recuperación DTBO, si es necesario.
      • Para la partición de recuperación A/B, el contenido se puede concatenar o inferir de boot y vendor_boot . Por ejemplo:
      • cmdline está concatenado con boot y vendor_boot cmdline .
      • El DTBO se puede inferir del encabezado vendor_boot .
    • imagen de disco RAM recovery
      • Recursos de recuperación
      • Para particiones de recuperación que no sean A/B, el contenido del disco RAM debe ser independiente; consulte Imágenes de recuperación . Por ejemplo:
      • lib/modules debe contener todos los módulos del kernel necesarios para iniciar el modo de recuperación
      • El disco RAM de recuperación debe contener init .
      • Para la partición de recuperación A/B, el disco RAM de recuperación se antepone al disco RAM genérico y al vendor_boot , por lo que no es necesario que sea independiente. Por ejemplo:
      • lib/modules puede 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 disco ram vendor_boot .
      • El enlace simbólico en /init puede existir, pero está eclipsado por el binario /init de primera etapa en la imagen de arranque.

Contenido de la imagen genérica del disco ram

El disco ram genérico contiene los siguientes componentes.

  • init
  • 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 init_boot , boot , recovery y vendor_boot . El valor de una variable booleana del tablero debe ser la cadena true o estar vacía (que es el valor predeterminado).

  • TARGET_NO_KERNEL . Esta variable indica si la compilación utiliza una imagen de inicio prediseñada. Si esta variable se establece en true , entonces configure BOARD_PREBUILT_BOOTIMAGE en la ubicación de la imagen de inicio prediseñada ( 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 boot . Cuando se usa GKI, esta variable está vacía y los recursos de recuperación deben moverse a vendor_boot .

  • BOARD_USES_GENERIC_KERNEL_IMAGE . Esta variable indica que la placa utiliza 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 del disco ram están integrados en vendor_boot .

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

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

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . Esta variable controla si las claves GSI AVB están integradas en vendor_boot .

    • Cuando se establece en true , si BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • Cuando está configurado, las claves GSI AVB están integradas 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 :

      • Cuando 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 inician con Android 12 y usan la partición recovery A/B deben configurar esta variable en true . Los dispositivos que se inician con Android 12 y no utilizan A/B deben configurar esta variable en false para mantener la imagen de recuperación autónoma.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . Esta variable controla si $OUT/boot*.img se copia a 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 se configuren las variables BOARD_AVB_INIT_BOOT* para vbmeta encadenado.

Combinaciones permitidas

Componente o variable Actualización de dispositivo sin partición recovery Actualización del dispositivo con partición recovery Iniciar dispositivo sin partición recovery Inicie el dispositivo con partición recovery A/B Inicie el dispositivo con una partición recovery 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 configurar PRODUCT_BUILD_RECOVERY_IMAGE en true o vacío. Para estos dispositivos, si se configura BOARD_RECOVERYIMAGE_PARTITION_SIZE , se crea una imagen recovery .

Habilitar vbmeta encadenado para el arranque

Se debe habilitar vbmeta encadenado 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 raíz

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

Configuraciones de producto

Los dispositivos que utilizan el disco ram genérico deben instalar una lista de archivos que pueden instalarse en el disco ram. 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 disco ram (en su lugar, mueva dichos archivos a vendor_ramdisk ).

Configurar 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. Android 13 se configura de manera similar a como estaba 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 se muestra en la Figura 4 .

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

  • Los dispositivos que se inician con Android 12 deben configurar BOARD_USES_RECOVERY_AS_BOOT para que esté vacío y use 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 disco ram vendor_boot contiene todos los recursos de recuperación, incluidos lib/modules (con los módulos del kernel del proveedor). En dichos dispositivos, la configuración del producto hereda de generic_ramdisk.mk .

Configuración de los valores de la TABLA

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 disco ram 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 disco ram genérico está concatenado después del disco ram vendor_boot , el enlace simbólico /init se sobrescribe. Cuando el dispositivo arranca en recuperación, el binario /system/bin/init es necesario para admitir el inicio de segunda etapa. El contenido de los discos RAM genéricos vendor_boot + es el siguiente:

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

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el disco ram 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 instale 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 init cambie la raíz a /system . Para ver ejemplos, consulte Sumas de comprobación de metadatos y compresión virtual A/B .

  • 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 la primera etapa .

Consola de 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 , necesita instalar la variante de 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 instalar explícitamente la variante recovery .

Para instalar explícitamente los módulos de recuperación, utilice 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 bajo 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 bajo vendor_ramdisk .

Sumas de comprobació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 de disco RAM 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 virtual A/B, snapuserd debe estar instalado 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 arranque.

El proceso de inicio 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 disco ram genérico al disco ram vendor_boot , el resultado de concatenar el disco ram genérico al disco ram de 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 admite compresión virtual A/B.

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 dedicada y de recuperación A/B

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

AB_OTA_PARTITIONS += recovery

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

  • Archivos fstab específicos del dispositivo

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

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

Configuración de los valores de la TABLA

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 disco ram 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 disco ram de arranque está concatenado después del disco ram recovery , el enlace simbólico /init se sobrescribe. Cuando el dispositivo arranca en modo de recuperación, el binario /system/bin/init es necesario para admitir el inicio de segunda etapa.

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

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

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

  • /init (de ramdisk genérico, creado a partir de init_first_stage )

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el disco ram genérico al 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 la instalación de módulos en vendor_ramdisk , consulte Consola de primera etapa , sumas de comprobación de metadatos y compresión virtual A/B .

Consola de primera etapa

Para instalar la variante vendor_ramdisk de los módulos, utilice 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 bajo vendor_ramdisk .

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

Sumas de comprobació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 de disco RAM 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, snapuserd debe estar instalado 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 arranque.

Al iniciar Android, el proceso de inicio no cambia. El vendor_boot + ramdisk genérico 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 proceso de recuperación + vendor_boot + ramdisk genérico es similar al proceso de recuperación existente, pero el kernel se carga desde la imagen boot en lugar de desde la imagen recovery . El proceso de inicio para el modo de recuperación es el siguiente.

  1. El gestor de arranque se inicia y luego hace lo siguiente:

    1. Empuja recovery + vendor_boot + ramdisk 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 / luego ejecuta /init desde el disco ram genérico.

  3. Se inicia la primera etapa y luego hace lo siguiente:

    1. Establece IsRecoveryMode() == true y ForceNormalBoot() == false .
    2. Carga módulos del kernel del proveedor desde /lib/modules .
    3. Llama a DoFirstStageMount() pero omite el montaje porque IsRecoveryMode() == true . (El dispositivo no libera el disco ram (porque / sigue siendo el mismo) pero llama a SetInitAvbVersionInRecovery() ).
    4. Inicia el inicio de la segunda etapa desde /system/bin/init desde el disco RAM 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 admite compresión virtual A/B.

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 llamada recovery sin sufijo de ranura. Dichos dispositivos incluyen:

  • dispositivos que no son A/B;
  • Dispositivos A/B y Virtual A/B, cuya partición de recuperación no se puede actualizar. (Esto es inusual).

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

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

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

  • La imagen del núcleo
  • La imagen del DTBO
  • Módulos del kernel en lib/modules
  • Inicio 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 hereda de generic_ramdisk.mk .

Configuración de los valores de la TABLA

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 disco RAM recovery debe contener un enlace simbólico /init -> /system/bin/init e init_second_stage.recovery en /system/bin/init . Cuando el dispositivo arranca en modo de recuperación, el binario /system/bin/init es necesario para admitir el inicio de primera y segunda etapa.

Cuando el dispositivo arranca en recovery , el contenido de los discos RAM recovery es el siguiente:

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

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

  • /init (desde ramdisk, creado desde init_first_stage )

Mover archivos fstab

Mueva todos los archivos fstab que se instalaron en el disco RAM genérico al disco ram recovery y al 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 y en el disco ram 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 módulos se instala en la raíz del disco RAM recovery . Para ver ejemplos sobre la instalación de módulos en vendor_ramdisk y el disco ram recovery , consulte Consola de primera etapa y sumas de comprobación de metadatos .

Consola de primera etapa

Para instalar la variante vendor_ramdisk de los módulos, utilice 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 bajo vendor_ramdisk .

Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), habilite la variante vendor_ramdisk de estos módulos 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 comprobació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 de disco ram 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 iniciar Android, el proceso de inicio no cambia. El vendor_boot + ramdisk genérico 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 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 para el modo de recuperación es el siguiente.

  1. El gestor de arranque se inicia y luego hace lo siguiente:

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

  2. El kernel monta el disco ram en / luego ejecuta /init , que es un enlace simbólico a /system/bin/init desde el disco ram recovery .

  3. Se inicia la primera etapa y luego hace lo siguiente:

    1. Establece IsRecoveryMode() == true y ForceNormalBoot() == false .
    2. Carga módulos del kernel del proveedor desde /lib/modules .
    3. Llama a DoFirstStageMount() pero omite el montaje porque IsRecoveryMode() == true . (El dispositivo no libera el disco ram (porque / sigue siendo el mismo) pero llama a SetInitAvbVersionInRecovery() ).
    4. Inicia el inicio de la segunda etapa desde /system/bin/init desde el disco RAM 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 disco ram 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 archivos del disco ram a tmpfs antes de liberar el disco ram para que init de la segunda etapa pueda leer este archivo para configurar las propiedades de la marca de tiempo de la imagen boot .