Partición de inicio genérica

En Android 12, la imagen genérica boot, a la que se hace referencia como Imagen genérica del kernel (GKI), contiene el ramdisk genérico y el kernel de GKI.

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

Para actualizar dispositivos que siguen usando Android 12 o versiones anteriores de kernel, el ramdisk genérico permanece donde estaba con No se requiere una nueva imagen de init_boot.

Para compilar un ramdisk genérico, mueve los recursos específicos del proveedor fuera del ramdisk de modo que el ramdisk genérico contenga solo la primera etapa init y una propiedad. que contiene información de marcas de tiempo.

En dispositivos que cumplan con las siguientes características:

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

  • Usa una partición recovery dedicada; sin cambios en el ramdisk recovery es necesario porque el ramdisk recovery es independiente.

Arquitectura

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

Inicia con Android 13, sin recuperación dedicada

Iniciar o actualizar dispositivo, GKI, sin recuperación

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

Realiza el lanzamiento con Android 13, dedicado y recuperación A/B (ramdisk dedicado)

Iniciar y actualizar el dispositivo, GKI, dedicado y la recuperación A/B

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

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

Realiza el lanzamiento con Android 13, recuperación dedicada y sin A/B (ramdisk dedicado)

Iniciar/actualizar el dispositivo, GKI y la recuperación dedicada y sin A/B

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

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

Inicia o actualiza a Android 12 (sin recuperación dedicada)

Iniciar o actualizar dispositivo, GKI, sin recuperación

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

Inicia o actualiza a Android 12, dedicado y recuperación A/B (ramdisk dedicado)

Iniciar y actualizar el dispositivo, GKI, dedicado y la recuperación A/B

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

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

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

Iniciar/actualizar el dispositivo, GKI y la recuperación dedicada y sin A/B

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

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

Actualiza a Android 12, recovery-as-boot (recovery-as-ramdisk).

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

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

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

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

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

Contenido de imágenes de arranque

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

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

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

  • Imagen genérica de boot

    • Versión del encabezado V3 o V4
      • Un boot_signature para la certificación boot.img de GKI (solo v4) El No se firmó el GKI certificado boot.img para el inicio verificado. Los OEM también deben firma el boot.img precompilado con una clave específica del dispositivo AVB .
      • Genérica cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel de GKI
    • Imagen genérica de ramdisk
      • Solo se incluye en boot imágenes de Android 12 y anteriores

  • vendor_boot imagen (para obtener más detalles, consulta Inicio del proveedor) Particiones)

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

  • Imagen recovery

    • Versión del encabezado V2
      • cmdline específico del dispositivo para la recuperación, si es necesario
      • Para las particiones de recuperación que no sean A/B, el contenido del encabezado debe independiente; ver Imágenes de recuperación. Por ejemplo:
      • cmdline no se concatena a boot ni a vendor_boot cmdline.
      • El encabezado especifica el DTBO de recuperación, si es necesario.
      • En el caso de las particiones de recuperación A/B, los contenidos se pueden concatenar o inferir desde boot y vendor_boot. Por ejemplo:
      • cmdline se concatena a boot y a vendor_boot cmdline.
      • DTBO se puede inferir del encabezado vendor_boot.
    • Imagen de ramdisk recovery
      • Recursos de recuperación
      • Para las particiones de recuperación que no sean A/B, el contenido del ramdisk debe independiente; ver Imágenes de recuperación. Por ejemplo:
      • lib/modules debe contener todos los módulos de kernel necesarios para iniciar 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 el ramdisk genérico y vendor_boot, por lo que no es necesario de forma independiente. Por ejemplo:
      • lib/modules puede contener solo los módulos de kernel adicionales necesarios para el modo de recuperación de inicio, además de los módulos de kernel en el ramdisk vendor_boot
      • Es posible que el symlink en /init exista, pero lo eclipsó el El objeto binario /init de la primera etapa en la imagen de arranque.

Contenido de imagen genérica de ramdisk

El ramdisk genérico contiene los siguientes componentes.

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

Integración de la imagen de arranque

Las marcas de compilación controlan cómo init_boot, boot, recovery y vendor_boot cómo se compilan las imágenes. 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 un modelo de inicio imagen. Si esta variable se establece en true, establece BOARD_PREBUILT_BOOTIMAGE. a la ubicación de la imagen de arranque compilada previamente (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

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

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

    Este es el interruptor de GKI a nivel de la placa. todas las siguientes variables restringido por esta variable.

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

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

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

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Esta variable controla si la GSI Las teclas AVB se compilan en vendor_boot.

    • Cuando se establece en true, si es BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Si está configurada, las teclas AVB de GSI están diseñadas para $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • Si no está configurada, las teclas AVB de GSI se diseñaron para $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Cuando está vacío, si es BOARD_RECOVERY_AS_ROOT:

      • Si está configurada, las teclas AVB de GSI están diseñadas para $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Si no está configurada, las teclas AVB de GSI se diseñaron para $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Esta variable controla si el La imagen de recovery contiene un kernel o no. Dispositivos que se lanzan con Android 12 y, con la partición A/B recovery, se debe configurar esto variable en true. Dispositivos que se lanzan con Android 12 y, con un valor que no sea A/B, debe establecer esta variable en false para conservar la imagen de recuperación independientes.

  • 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 vacía esta variable.

  • 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 la Variables BOARD_AVB_INIT_BOOT* que se establecerán para vbmeta encadenado.

Combinaciones permitidas

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

Se pueden configurar los dispositivos con una partición recovery dedicada PRODUCT_BUILD_RECOVERY_IMAGE a true o vacío. Para estos dispositivos, si Se configura BOARD_RECOVERYIMAGE_PARTITION_SIZE y se compila una imagen recovery.

Habilitar vbmeta en cadena para el inicio

Se debe habilitar vbmeta en cadena para las imágenes boot y init_boot. Especificar 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

Por ejemplo, consulta esta o modificar datos.

System-as-root

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

Configuraciones de productos

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

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

El archivo generic_ramdisk.mk también previene que otros archivos makefile instalando otros archivos en el ramdisk (mover estos archivos a vendor_ramdisk en su lugar).

Configurar dispositivos

Las instrucciones de configuración son diferentes entre los dispositivos que se lanzan con Android. 13, la actualización a Android 12 y el lanzamiento con Android 12. Android 13 se configuran de manera similar a como se configuraron con Android 12.

  • Dispositivos que se actualizan a Android 12:

    • Puede conservar el valor de BOARD_USES_RECOVERY_AS_BOOT. Si lo hacen, usa parámetros de configuración heredados y las nuevas variables de compilación deben estar vacías. Si es así, dispositivos:

      • Si estableces BOARD_USES_RECOVERY_AS_BOOT en true, la arquitectura será la siguiente: como se muestra en la Figura 3.

      • Si estableces BOARD_USES_RECOVERY_AS_BOOT como vacío, la arquitectura será como se muestra Figura 4:

    • Se puede configurar BOARD_USES_RECOVERY_AS_BOOT como vacío. Si lo hacen, usarán los parámetros de configuración nuevos. Si tales dispositivos:

      • No uses una partición recovery dedicada; la arquitectura es como se muestra de la figura 1, y la opción de configuración del dispositivo es Option 1

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

  • Los dispositivos que se lanzan con Android 12 deben establecerse BOARD_USES_RECOVERY_AS_BOOT para vaciarla y usar configuraciones nuevas Si es así, dispositivos:

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

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

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

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

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

Establece valores de BOARD

Configura los siguientes valores:

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

El ramdisk vendor_boot puede contener un symlink de /init a /system/bin/init. y init_second_stage.recovery a las /system/bin/init. Sin embargo, debido a que el El ramdisk genérico se concatena después del ramdisk vendor_boot, el disco /init y se reemplazará el symlink. Cuando el dispositivo se inicie en el modo de recuperación, el Se necesita el objeto binario /system/bin/init para admitir el inicio de la segunda etapa. El contenido de vendor_boot + ramdisks genéricos son los siguientes:

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

Mover los archivos fstab

Mueve los archivos fstab que se instalaron al disco RAM genérico a vendor_ramdisk Por ejemplo, consulta esta o modificar datos.

Instala módulos

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

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

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

Consola de la primera etapa

Porque la consola de la primera etapa se inicia antes de que init cambie a la raíz /first_stage_ramdisk, debes instalar la variante recovery de los módulos. De forma predeterminada, ambas variantes de módulo se instalan en build/make/target/product/base_vendor.mk: Por lo tanto, si el archivo makefile del dispositivo hereda a partir de ese archivo, no necesitas instalar la variante recovery de forma explícita.

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

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

De esta manera, se garantiza que linker, sh y toybox se instalen en $ANDROID_PRODUCT_OUT/recovery/root/system/bin, que luego se instala en /system/bin por debajo de vendor_ramdisk.

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

PRODUCT_PACKAGES += adbd.recovery

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

Sumas de comprobación de metadatos

Para admitir metadatos sumas de comprobación durante el montaje de la primera etapa, los dispositivos que no son compatibles con GKI instalan el disco RAM de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin

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

Por ejemplo, consulta esta lista de cambios.

Compresión A/B virtual

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

Cambios en el proceso de inicio

El proceso de inicio en recuperación o en Android no cambia. siguiente excepción:

  • El ramdisk build.prop pasa a /second_stage_resources, por lo que la segunda etapa init puede leer la marca de tiempo de compilación del inicio.

Debido a que los recursos se mueven del ramdisk genérico a ramdisk vendor_boot, el resultado de la concatenación de ramdisk genérico a ramdisk vendor_boot no cambia.

Habilitar e2fsck

Los archivos makefile del dispositivo se pueden heredar de lo siguiente:

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

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

La instalación de los archivos makefile del producto $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. En entorno de ejecución, la primera etapa, init, cambia la raíz a /first_stage_ramdisk y, luego, se ejecuta /system/bin/e2fsck.

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

Usa esta opción para dispositivos con particiones A/B recovery. es decir, El dispositivo tiene recovery_a y recovery_b partition. Tales dispositivos incluyen Dispositivos A/B y A/B virtuales en los que la partición de recuperación se puede actualizar, con la siguiente configuración:

AB_OTA_PARTITIONS += recovery

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

  • Archivos fstab específicos del dispositivo

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

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

Establece valores de BOARD

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

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

El ramdisk recovery puede contener un symlink /init -> /system/bin/init. init_second_stage.recovery a las /system/bin/init. Sin embargo, debido a que la estructura el ramdisk se concatena después del ramdisk recovery, el symlink /init se se sobrescribirá. Cuando el dispositivo se inicia en modo de recuperación, /system/bin/init para admitir init de segunda etapa.

Cuando se inicia el dispositivo en recovery, el contenido de recovery + vendor_boot + los ramdisks genéricos son los siguientes:

  • /init (de ramdisk, compilado a partir de init_first_stage)
  • /system/bin/init (del ramdisk de recovery, compilado a partir de init_second_stage.recovery, y se ejecutó desde /init)

Cuando el dispositivo se inicia en Android, el contenido de vendor_boot + genérico Los ramdisks son las siguientes:

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

Mover los archivos fstab

Mueve los archivos fstab que se instalaron al disco RAM genérico al vendor_ramdisk Por ejemplo, consulta esta o modificar datos.

Instala módulos

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

Consola de la primera etapa

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Si el ramdisk vendor_boot se cargue en modo de recuperación, el módulo también está disponible en recovery. Si el botón El ramdisk vendor_boot no se cargó en el modo de recuperación, por lo que el dispositivo puede también instala adbd.recovery.

Sumas de comprobación de metadatos

Para admitir metadatos sumas de comprobación durante el montaje de la primera etapa, los dispositivos que no son compatibles con GKI instalan el disco RAM de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin

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

Por ejemplo, consulta esta lista de cambios.

Compresión A/B virtual

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

Cambios en el proceso de inicio

Cuando inicias Android, el proceso no cambia. El botón de +vendor_boot El ramdisk genérico es similar al proceso de inicio existente, con la excepción de que fstab cargas desde vendor_boot. Como system/bin/recovery no existe, first_stage_init lo administra como un inicio normal.

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

  1. El bootloader se inicia y, luego, hace lo siguiente:

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

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

  3. Se inicia el init de la primera etapa y, luego, hace lo siguiente:

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

Habilitar e2fsck

Los archivos makefile del dispositivo se pueden heredar de lo siguiente:

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

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

La instalación de los archivos makefile del producto $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. En del entorno de ejecución, la primera etapa, init, ejecuta /system/bin/e2fsck.

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

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

  • dispositivos que no sean A/B;
  • Dispositivos A/B y A/B virtuales, de los cuales no está la partición de recuperación actualizables. (este no es un caso común).

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

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

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

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

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

Establece valores de BOARD

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

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

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

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

  • /init -> /system/bin/init (del ramdisk de recovery)
  • /system/bin/init (del ramdisk de recovery, compilado a partir de init_second_stage.recovery, y se ejecutó desde /init)

Cuando el dispositivo se inicia en Android, el contenido de vendor_boot + genérico Los ramdisks son las siguientes:

  • /init (de ramdisk, compilado a partir de init_first_stage)

Mover los archivos fstab

Mueve los archivos fstab que se instalaron al disco RAM genérico al ramdisk vendor_ramdisk y recovery. Por ejemplo, consulta esta o modificar datos.

Instala módulos

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

Consola de la primera etapa

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

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

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

Sumas de comprobación de metadatos

Para admitir metadatos sumas de comprobación durante el montaje de la primera etapa, los dispositivos que no son compatibles con GKI instalan el disco RAM de los siguientes módulos. Para agregar compatibilidad con GKI, mueve los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin

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

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

Cambios en el proceso de inicio

Cuando inicias Android, el proceso no cambia. El botón de +vendor_boot El ramdisk genérico es similar al proceso de inicio existente, con la excepción de que fstab cargas desde vendor_boot. Como system/bin/recovery no existe, first_stage_init lo administra como un inicio normal.

Cuando se inicia en modo de recuperación, el proceso de inicio no cambia. La recuperación el ramdisk se cargará de la misma forma que el proceso de recuperación existente. El kernel se carga desde la imagen recovery. El el proceso de inicio para el modo de recuperación es el siguiente.

  1. El bootloader se inicia y, luego, hace lo siguiente:

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

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

  3. Se inicia el init de la primera etapa y, luego, hace lo siguiente:

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

Marcas de tiempo de imágenes de arranque

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

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

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

  • En el tiempo de ejecución, primera etapa init copias archivos del ramdisk a tmpfs antes de liberarlo para que la etapa init puede leer este archivo para establecer boot propiedades de marca de tiempo de imágenes.