En Android 12, la imagen boot
genérica, denominada Imagen de kernel genérica (GKI) , contiene el ramdisk genérico y el kernel GKI.
Para los dispositivos que se inician con Android 13, el ramdisk genérico se elimina de la imagen boot
y se coloca en una imagen init_boot
separada. Este cambio deja la imagen boot
solo con el kernel GKI.
Para actualizar dispositivos que continúan usando Android 12 o versiones anteriores del kernel, el ramdisk genérico permanece donde estaba sin necesidad de una nueva imagen init_boot
.
Para crear un ramdisk genérico, mueva los recursos específicos del proveedor fuera del ramdisk de modo que el ramdisk genérico contenga solo init
de la primera etapa y un archivo de propiedades que contenga información de marca de tiempo.
En dispositivos que:
No use una partición
recovery
dedicada, todos los bits de recuperación se mueven del ramdisk genérico al ramdiskvendor_boot
.Utilice una partición
recovery
dedicada, no se necesita ningún cambio en el ramdiskrecovery
porque el ramdiskrecovery
es autónomo.
Arquitectura
Los siguientes diagramas ilustran la arquitectura para dispositivos que ejecutan Android 12 y superior. El dispositivo que se inicia con Android 13 tiene una nueva imagen init_boot
que contiene el ramdisk genérico. Los dispositivos que se actualizan de Android 12 a Android 13 usan la misma arquitectura que con Android 12.
Lanzamiento con Android 13, sin recuperación dedicada
Figura 1. Dispositivos que se inician o actualizan a Android 13, con GKI, sin recuperación dedicada
Lanzamiento con Android 13, dedicado y recuperación A/B (ramdisk dedicado)
Figura 2. Dispositivos que se inician o actualizan a Android 13, con GKI, dedicado y recuperación A/B
Consulte esta figura si el dispositivo tiene particiones recovery_a
y recovery_b
.
Lanzamiento con Android 13, recuperación dedicada y no A/B (ramdisk dedicado)
Figura 3. Dispositivos que se inician o actualizan a Android 13, con GKI, recuperación dedicada y no A/B
Consulte esta figura si el dispositivo tiene una partición denominada recovery
sin un sufijo de ranura.
Inicie o actualice a Android 12, sin recuperación dedicada
Figura 4. Dispositivos que se inician o actualizan a Android 12, con GKI, sin recuperación dedicada
Inicie o actualice a Android 12, recuperación dedicada y A/B (ramdisk dedicado)
Figura 5. Dispositivos que se inician o actualizan a Android 12, con GKI, dedicado y recuperación A/B
Consulte esta figura si el dispositivo tiene particiones recovery_a
y recovery_b
.
Inicie o actualice a Android 12, recuperación dedicada y no A/B (ramdisk dedicado)
Figura 6. Dispositivos que se inician o actualizan a Android 12, con GKI, recuperación dedicada y no A/B
Consulte esta figura si el dispositivo tiene una partición denominada recovery
sin un sufijo de ranura.
Actualice a Android 12, recuperación como arranque (recuperación como ramdisk)
Figura 7. Dispositivos que se actualizan a Android 12, sin GKI, recuperación como arranque
Actualice a Android 12, recuperación dedicada (ramdisk dedicado)
Figura 8. Dispositivos que se actualizan a Android 12, sin GKI, recuperación dedicada
Contenido de las imágenes de arranque
Las imágenes de arranque de Android contienen lo siguiente.
Imagen
init_boot
agregada para dispositivos que se inician con Android 13- Cabecera versión V4
- Imagen ramdisk genérica
Imagen
boot
genérica- Versión de cabecera V3 o V4
- Una
boot_signature
para la certificación GKI boot.img (solo v4). Elboot.img
de GKI certificado no está firmado para un arranque verificado. Los OEM aún deben firmar elboot.img
precompilado con una clave AVB específica del dispositivo. -
cmdline
genérica (GENERIC_KERNEL_CMDLINE
) - Núcleo GKI
- Una
- Imagen ramdisk genérica
- Solo se incluye en las imágenes
boot
de Android 12 y versiones anteriores
- Solo se incluye en las imágenes
- Versión de cabecera V3 o V4
imagen
vendor_boot
(para obtener más información, consulte Particiones de arranque de proveedores )- encabezado
vendor_boot
-
cmdline
específica del dispositivo (BOARD_KERNEL_CMDLINE
)
-
- imagen de ramdisk
vendor_boot
-
lib/modules
- Recursos de recuperación (si no hay una recuperación dedicada)
-
- imagen
dtb
- encabezado
imagen
recovery
- Versión de encabezado V2
-
cmdline
específica del dispositivo para la recuperación, si es necesario - Para la partición de recuperación que no es A/B, el contenido del encabezado debe ser independiente; consulte Imágenes de recuperación . Por ejemplo:
-
cmdline
no está concatenado conboot
yvendor_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
yvendor_boot
. Por ejemplo: -
cmdline
se concatena conboot
yvendor_boot
cmdline
. - DTBO se puede inferir del encabezado
vendor_boot
.
-
- imagen de ramdisk
recovery
- Recursos de recuperación
- Para la partición de recuperación que no es A/B, el contenido del ramdisk debe ser independiente; consulte Imágenes de recuperación . Por ejemplo:
-
lib/modules
debe contener todos los módulos del núcleo necesarios para iniciar el modo de recuperación - El ramdisk de recuperación debe contener
init
. - Para la partición de recuperación A/B, el ramdisk de recuperación se antepone al ramdisk genérico y
vendor_boot
, por lo que no es necesario que sea independiente. Por ejemplo: -
lib/modules
pueden contener solo módulos de kernel adicionales necesarios para iniciar el modo de recuperación además de los módulos de kernel en el ramdiskvendor_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.
- Versión de encabezado V2
Contenido genérico de la imagen ramdisk
El ramdisk genérico contiene los siguientes componentes.
-
init
- Añadido
system/etc/ramdisk/build.prop
-
ro. PRODUCT .bootimg.* build
- Directorios vacíos para puntos de montaje:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
-
first_stage_ramdisk/
- Directorios vacíos duplicados para puntos de montaje:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
- Directorios vacíos duplicados para puntos de montaje:
Integración de imagen de arranque
Los indicadores de compilación controlan cómo se compilan las imágenes init_boot
, boot
, recovery
y vendor_boot
. El valor de una variable de tablero booleana debe ser la cadena true
o estar vacía (que es el valor predeterminado).
TARGET_NO_KERNEL
. Esta variable indica si la compilación usa una imagen de arranque preconstruida. Si esta variable se establece entrue
, establezcaBOARD_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 imagenrecovery
como imagen deboot
. Cuando se usa GKI, esta variable está vacía y los recursos de recuperación se deben mover avendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Esta variable indica que la placa usa GKI. Esta variable no afecta a sysprops ni aPRODUCT_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 envendor_boot
.Cuando se establece en
true
, los recursos de recuperación se compilan solo envendor-ramdisk/
y no se compilan enrecovery/root/
.Cuando están vacíos, los recursos de recuperación se compilan solo en
recovery/root/
y no se compilan envendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Esta variable controla si las claves GSI AVB se construyen paravendor_boot
.Cuando se establece en
true
, siBOARD_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 imagenrecovery
contiene un kernel o no. Los dispositivos que se inicien con Android 12 y usen la particiónrecovery
A/B deben establecer esta variable entrue
. Los dispositivos que se inician con Android 12 y no usan A/B deben establecer esta variable enfalse
para mantener la imagen de recuperación independiente.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
. Esta variable controla si$OUT/boot*.img
se copia enIMAGES/
en los archivos de destino.aosp_arm64
debe establecer esta variable entrue
.Otros dispositivos deben dejar esta variable vacía.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
. Esta variable controla si se generainit_boot.img
y establece el tamaño. Cuando se configura, el ramdisk genérico se agrega ainit_boot.img
en lugar deboot.img
y requiere que las variablesBOARD_AVB_INIT_BOOT*
se configuren para vbmeta encadenado
Combinaciones permitidas
componente o variable | Actualizar dispositivo sin partición recovery | Actualizar dispositivo con partición recovery | Iniciar dispositivo sin partición recovery | Iniciar dispositivo con partición recovery A/B | Iniciar dispositivo con partición recovery no A/B | aosp_arm64 |
---|---|---|---|---|---|---|
Contiene boot | Sí | Sí | Sí | Sí | Sí | Sí |
Contiene init_boot (Android 13) | No | No | Sí | Sí | Sí | Sí |
Contiene vendor_boot | opcional | opcional | Sí | Sí | Sí | No |
Contiene recovery | No | Sí | No | Sí | Sí | No |
BOARD_USES_RECOVERY_AS_BOOT | true | vacío | vacío | vacío | vacío | vacío |
BOARD_USES_GENERIC_KERNEL_IMAGE | vacío | vacío | true | true | true | true |
PRODUCT_BUILD_RECOVERY_IMAGE | vacío | true o vacío | vacío | true o vacío | true o vacío | vacío |
BOARD_RECOVERYIMAGE_PARTITION_SIZE | vacío | > 0 | vacío | > 0 | > 0 | vacío |
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT | vacío | vacío | true | vacío | vacío | vacío |
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT | vacío | vacío | true | true | true | vacío |
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE | vacío | vacío | vacío | true | vacío | vacío |
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES | vacío | vacío | vacío | vacío | vacío | true |
Los dispositivos con una partición recovery
dedicada pueden establecer PRODUCT_BUILD_RECOVERY_IMAGE
en true
o vacío. Para estos dispositivos, si se establece BOARD_RECOVERYIMAGE_PARTITION_SIZE
, se crea una imagen recovery
.
Habilitar vbmeta encadenado para el arranque
El vbmeta encadenado debe estar habilitado para las imágenes boot
e init_boot
. Especifique lo siguiente:
BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2
BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3
Para ver un ejemplo, consulte este cambio .
Sistema como root
System-as-root no es compatible con dispositivos que usan GKI. En dichos dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE
debe estar vacío. System-as-root tampoco es compatible con dispositivos que usan particiones dinámicas.
Configuraciones de productos
Los dispositivos que utilizan el ramdisk genérico deben instalar una lista de archivos que pueden instalarse en el ramdisk. Para hacerlo, especifique lo siguiente en device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
El archivo generic_ramdisk.mk
también evita que otros archivos MAKE instalen accidentalmente otros archivos en el ramdisk (en su lugar, mueva dichos archivos a vendor_ramdisk
).
Configuración de dispositivos
Las instrucciones de configuración difieren entre los dispositivos que se inician con Android 13, se actualizan a Android 12 y se inician con Android 12. La configuración de Android 13 es similar a la de Android 12
Dispositivos que se actualizan a Android 12:
Puede conservar el valor de
BOARD_USES_RECOVERY_AS_BOOT
. Si lo hacen, están usando configuraciones heredadas y las nuevas variables de compilación deben estar vacías. Si tales dispositivos:Establezca
BOARD_USES_RECOVERY_AS_BOOT
entrue
, 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
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
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
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
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
compila solo GKI (y no vendor_boot
o recovery), no es un objetivo completo. Para las configuraciones de compilación aosp_arm64
, consulte generic_arm64
.
Opción 1: Sin partición de recuperación dedicada
Los dispositivos sin una partición recovery
contienen la imagen boot
genérica en la partición boot
. El ramdisk vendor_boot
contiene todos los recursos de recuperación, incluidos lib/modules
(con módulos de kernel de proveedor). En dichos dispositivos, la configuración del producto se hereda de generic_ramdisk.mk
.
Configuración de los valores de la TARJETA
Establezca los siguientes valores:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Init binarios y enlaces simbólicos
El ramdisk vendor_boot
puede contener un enlace simbólico /init
a /system/bin/init
e init_second_stage.recovery
en /system/bin/init
. Sin embargo, debido a que el ramdisk genérico se concatena después del ramdisk vendor_boot
, el enlace simbólico /init
se sobrescribe. Cuando el dispositivo inicia la recuperación, se necesita el binario /system/bin/init
para admitir el inicio de la segunda etapa. El contenido de vendor_boot
+ ramdisks genéricos es el siguiente:
-
/init
(desde ramdisk genérico, construido desdeinit_first_stage
) -
/system/bin/init
(devendor_ramdisk
, creado a partir deinit_second_stage.recovery
)
Mover archivos fstab
Mueva los archivos fstab
que se instalaron en el ramdisk genérico a vendor_ramdisk
. Para ver un ejemplo, consulte este cambio .
Instalación de módulos
Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk
(omita este paso si no tiene ningún módulo específico del dispositivo para instalar).
Utilice la variante
vendor_ramdisk
del módulo cuando el módulo se instala en/first_stage_ramdisk
. Este módulo debería estar disponible después de queinit
cambie la raíz a/first_stage_ramdisk
pero antes de queinit
cambie la raíz a/system
. Para ver ejemplos, consulte Sumas de verificación de metadatos y compresión A/B virtual .Utilice la variante
recovery
del módulo cuando el módulo se instale en/
. Este módulo debería estar disponible antes de queinit
cambie la raíz a/first_stage_ramdisk
. Para obtener detalles sobre la instalación de módulos en/
, consulte Consola de primera etapa .
consola primera etapa
Debido a que la consola de la primera etapa se inicia antes de que init
cambie la raíz a /first_stage_ramdisk
, debe instalar la variante de recovery
de los módulos. De manera predeterminada, ambas variantes del módulo se instalan en build/make/target/product/base_vendor.mk
, por lo que si el archivo MAKE del dispositivo se hereda de ese archivo, no necesita instalar explícitamente la variante recovery
.
Para instalar explícitamente los módulos de recuperación, use lo siguiente.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
Esto garantiza que el linker
, sh
y toybox
se instalen en $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que luego se instala en /system/bin
debajo de vendor_ramdisk
.
Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), use lo siguiente.
PRODUCT_PACKAGES += adbd.recovery
Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que luego se instala en /system/bin
debajo de vendor_ramdisk
.
Sumas de verificación de metadatos
Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para ver un ejemplo, consulte esta lista de cambios .
Compresión virtual A/B
Para admitir la compresión A/B virtual, se debe instalar snapuserd
en vendor_ramdisk
. El dispositivo debe heredar de virtual_ab_ota/compression.mk
, que instala la variante de snapuserd
de vendor_ramdisk
.
Cambios en el proceso de arranque
El proceso de arranque en recuperación o en Android no cambia, con la siguiente excepción:
- Ramdisk
build.prop
se mueve a/second_stage_resources
para queinit
de la segunda etapa pueda leer la marca de tiempo de compilación del arranque.
Debido a que los recursos se mueven del ramdisk genérico al ramdisk vendor_boot
, el resultado de concatenar el ramdisk genérico al ramdisk vendor_boot
no cambia.
Hacer que e2fsck esté disponible
Los archivos MAKE del dispositivo pueden heredar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
si el dispositivo admite A/B virtual pero no compresión.virtual_ab_ota/compression.mk
si el dispositivo es compatible con la compresión A/B virtual.
Los archivos MAKE del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck
. En tiempo de ejecución, el init
de la primera etapa cambia la raíz a /first_stage_ramdisk
y luego ejecuta /system/bin/e2fsck
.
Opción 2a: Partición de recuperación dedicada y A/B
Use esta opción para dispositivos con particiones recovery
A/B; es decir, el dispositivo tiene una recovery_b partition
recovery_a
y recovery_b. Tales dispositivos incluyen dispositivos A/B y Virtual A/B cuya partición de recuperación es actualizable, con la siguiente configuración:
AB_OTA_PARTITIONS += recovery
El ramdisk del vendor_boot
contiene los bits del proveedor del ramdisk y los módulos del kernel del proveedor, incluidos los siguientes:
Archivos
fstab
específicos del dispositivolib/modules
(incluye módulos de kernel de proveedores)
El ramdisk recovery
contiene todos los recursos de recuperación. En dichos dispositivos, la configuración del producto se hereda de generic_ramdisk.mk
.
Configuración de los valores de la TARJETA
Establezca los siguientes valores para dispositivos con partición recovery
A/B:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Init binarios y enlaces simbólicos
El ramdisk recovery
puede contener un enlace simbólico /init -> /system/bin/init
e init_second_stage.recovery
en /system/bin/init
. Sin embargo, debido a que el ramdisk de arranque se concatena después del ramdisk recovery
, el enlace simbólico /init
se sobrescribe. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el binario /system/bin/init
para admitir el inicio de la segunda etapa.
Cuando el dispositivo arranca en recovery
, el contenido de recovery
+ vendor_boot
+ ramdisks genéricos es el siguiente:
-
/init
(desde ramdisk, construido desdeinit_first_stage
) -
/system/bin/init
(desderecovery
ramdisk, creado desdeinit_second_stage.recovery
y ejecutado desde/init
)
Cuando el dispositivo arranca en Android, el contenido de vendor_boot
+ ramdisks genéricos es el siguiente:
-
/init
(desde ramdisk genérico, construido desdeinit_first_stage
)
Mover archivos fstab
Mueva todos los archivos fstab
que se instalaron en el disco RAM genérico al disco ramdisk del vendor_ramdisk
. Para ver un ejemplo, consulte este cambio .
Instalación de módulos
Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk
(omita este paso si no tiene ningún módulo específico del dispositivo para instalar). Init
no cambia de raíz. La variante de módulos vendor_ramdisk
se instala en la raíz de vendor_ramdisk
. Para ver ejemplos sobre cómo instalar módulos en vendor_ramdisk
, consulte Consola de primera etapa , sumas de verificación de metadatos y compresión A/B virtual .
consola primera etapa
Para instalar la variante vendor_ramdisk
de los módulos, use lo siguiente:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Esto garantiza que el linker
, sh
y toybox
se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que luego se instala en /system/bin
debajo de vendor_ramdisk
.
Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), habilite la variante de estos módulos de vendor_ramdisk
cargando los parches relevantes en AOSP, luego use lo siguiente:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
. Si el ramdisk vendor_boot
se carga en modo de recuperación, el módulo también está disponible en recovery
. Si el ramdisk vendor_boot
no está cargado en modo de recuperación, el dispositivo también puede instalar opcionalmente adbd.recovery
.
Sumas de verificación de metadatos
Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para ver un ejemplo, consulte esta lista de cambios .
Compresión virtual A/B
Para admitir la compresión Virtual A/B, se debe instalar snapuserd
en vendor_ramdisk
. El dispositivo debe heredar de virtual_ab_ota/compression.mk
, que instala la variante de snapuserd
de vendor_ramdisk
.
Cambios en el proceso de arranque
Al arrancar en Android, el proceso de arranque no cambia. El ramdisk genérico vendor_boot
+ es similar al proceso de arranque existente, excepto que fstab
se carga desde vendor_boot
. Debido a que system/bin/recovery
no existe, first_stage_init
lo maneja como un arranque normal.
Al iniciar en modo de recuperación, el proceso de inicio cambia. El disco de recuperación + vendor_boot
+ ramdisk genérico es similar al proceso de recuperación existente, pero el núcleo se carga desde la imagen boot
en lugar de desde la imagen recovery
. El proceso de arranque para el modo de recuperación es el siguiente.
El cargador de arranque se inicia, luego hace lo siguiente:
- Empuja recovery +
vendor_boot
+ ramdisk genérico a/
. (Si el OEM duplica los módulos del kernel en el ramdisk de recuperación agregándolos aBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
es opcional). - Ejecuta el kernel desde la partición
boot
.
- Empuja recovery +
Kernel monta ramdisk en
/
luego ejecuta/init
desde el ramdisk genérico.Inicia la primera etapa, luego hace lo siguiente:
- Establece
IsRecoveryMode() == true
yForceNormalBoot() == false
. - Carga los módulos del kernel del proveedor desde
/lib/modules
. - Llama a
DoFirstStageMount()
pero omite el montaje porqueIsRecoveryMode() == true
. (El dispositivo no libera ramdisk (porque/
sigue siendo el mismo) pero llama aSetInitAvbVersionInRecovery()
). - Inicia el inicio de la segunda etapa desde
/system/bin/init
desde el ramdiskrecovery
.
- Establece
Hacer que e2fsck esté disponible
Los archivos MAKE del dispositivo pueden heredar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
si el dispositivo admite A/B virtual pero no compresión.virtual_ab_ota/compression.mk
si el dispositivo es compatible con la compresión A/B virtual.
Los archivos MAKE del producto instalan $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck
. En tiempo de ejecución, la primera etapa init
ejecuta /system/bin/e2fsck
.
Opción 2b: partición de recuperación dedicada y no A/B
Utilice esta opción para dispositivos con una partición recovery
que no sea A/B; es decir, el dispositivo tiene una partición denominada recovery
sin un sufijo de ranura. Tales dispositivos incluyen:
- dispositivos no A/B;
- Dispositivos A/B y Virtual A/B, de los cuales la partición de recuperación no es actualizable. (Esto es inusual).
El ramdisk del vendor_boot
contiene los bits del proveedor del ramdisk y los módulos del kernel del proveedor, incluidos los siguientes:
- Archivos
fstab
específicos del dispositivo -
lib/modules
(incluye módulos de kernel de proveedores)
La imagen recovery
debe ser independiente. Debe contener todos los recursos necesarios para iniciar el modo de recuperación, incluidos:
- La imagen del núcleo
- La imagen DTBO
- Módulos del kernel en
lib/modules
- Inicialización de primera etapa como enlace simbólico
/init -> /system/bin/init
- Binario de inicio de segunda etapa
/system/bin/init
- Archivos
fstab
específicos del dispositivo - Todos los demás recursos de recuperación, incluido el binario
recovery
, etc. - etc.
En dichos dispositivos, la configuración del producto se hereda de generic_ramdisk.mk
.
Configuración de los valores de la TARJETA
Establezca los siguientes valores para dispositivos que no sean A/B:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Init binarios y enlaces simbólicos
El ramdisk recovery
debe contener un enlace simbólico /init -> /system/bin/init
e init_second_stage.recovery
en /system/bin/init
. Cuando el dispositivo se inicia en el modo de recuperación, se necesita el binario /system/bin/init
para admitir el inicio de la primera y la segunda etapa.
Cuando el dispositivo inicia recovery
, el contenido de los ramdisks recovery
es el siguiente:
-
/init -> /system/bin/init
(desde el ramdiskrecovery
) -
/system/bin/init
(desderecovery
ramdisk, creado desdeinit_second_stage.recovery
y ejecutado desde/init
)
Cuando el dispositivo arranca en Android, el contenido de vendor_boot
+ ramdisks genéricos es el siguiente:
-
/init
(desde ramdisk, construido desdeinit_first_stage
)
Mover archivos fstab
Mueva todos los archivos fstab
que se instalaron en el disco RAM genérico al vendor_ramdisk
y al disco RAM recovery
. Para ver un ejemplo, consulte este cambio .
Instalación de módulos
Si lo desea, puede instalar módulos específicos del dispositivo en vendor_ramdisk
y ramdisk recovery
(omita este paso si no tiene ningún módulo específico del dispositivo para instalar). init
no cambia de raíz. La variante de módulos vendor_ramdisk
se instala en la raíz de vendor_ramdisk
. La variante recovery
de los módulos se instala en la raíz del ramdisk recovery
. Para ver ejemplos sobre la instalación de módulos en vendor_ramdisk
y recovery
ramdisk, consulte Consola de primera etapa y sumas de verificación de metadatos .
consola primera etapa
Para instalar la variante vendor_ramdisk
de los módulos, use lo siguiente:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Esto garantiza que el linker
, sh
y toybox
se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que luego se instala en /system/bin
debajo de vendor_ramdisk
.
Para agregar los módulos necesarios para la consola de la primera etapa (por ejemplo, adbd), habilite la variante de estos módulos de vendor_ramdisk
cargando los parches relevantes en AOSP, luego use lo siguiente:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Esto garantiza que los módulos especificados se instalen en $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
.
Para instalar la variante recovery
de los módulos, reemplace vendor_ramdisk
con recovery
:
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
adbd.recovery \
Sumas de verificación de metadatos
Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa, los dispositivos que no admiten GKI instalan la variante ramdisk de los siguientes módulos. Para agregar soporte para GKI, mueva los módulos a $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para admitir sumas de verificación de metadatos durante el montaje de la primera etapa en la recuperación, habilite la variante de recuperación de estos módulos e instálelos también.
Cambios en el proceso de arranque
Al arrancar en Android, el proceso de arranque no cambia. El ramdisk genérico vendor_boot
+ es similar al proceso de arranque existente, excepto que fstab
se carga desde vendor_boot
. Debido a que system/bin/recovery
no existe, first_stage_init
lo maneja como un arranque normal.
Al iniciar en modo de recuperación, el proceso de inicio no cambia. El ramdisk de recuperación se carga de la misma manera que el proceso de recuperación existente. El kernel se carga desde la imagen recovery
. El proceso de arranque para el modo de recuperación es el siguiente.
El cargador de arranque se inicia, luego hace lo siguiente:
- Empuja el ramdisk de recuperación a
/
. - Ejecuta el kernel desde la partición
recovery
.
- Empuja el ramdisk de recuperación a
Kernel monta el ramdisk en
/
luego ejecuta/init
, que es un enlace simbólico a/system/bin/init
desde el ramdiskrecovery
.Inicia la primera etapa, luego hace lo siguiente:
- Establece
IsRecoveryMode() == true
yForceNormalBoot() == false
. - Carga los módulos del kernel del proveedor desde
/lib/modules
. - Llama a
DoFirstStageMount()
pero omite el montaje porqueIsRecoveryMode() == true
. (El dispositivo no libera ramdisk (porque/
sigue siendo el mismo) pero llama aSetInitAvbVersionInRecovery()
). - Inicia el inicio de la segunda etapa desde
/system/bin/init
desde el ramdiskrecovery
.
- Establece
Marcas de tiempo de la imagen de arranque
El siguiente código es un archivo de marca de tiempo de imagen boot
de ejemplo.
####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file
En el momento de la compilación, se agrega un archivo
system/etc/ramdisk/build.prop
al ramdisk genérico. Este archivo contiene información de marca de tiempo de la compilación.En tiempo de ejecución,
init
de la primera etapa copia los archivos del ramdisk atmpfs
antes de liberar el ramdisk para queinit
de la segunda etapa pueda leer este archivo y establecer las propiedades de la marca de tiempo de la imagenboot
.