En Android 10, el sistema de archivos raíz ya no se incluye en ramdisk.img
y, en cambio, se fusiona con system.img
(es decir, system.img
siempre se crea como si se hubiera configurado BOARD_BUILD_SYSTEM_ROOT_IMAGE
). Dispositivos que se inician con Android 10:
- Use un diseño de partición del sistema como raíz (aplicado automáticamente por la compilación sin opciones para cambiar el comportamiento).
- Debe usar un ramdisk, que es necesario para dm-linear.
- Debe establecer
BOARD_BUILD_SYSTEM_ROOT_IMAGE
enfalse
. Esta configuración se usa solo para diferenciar entre dispositivos que usan un ramdisk y dispositivos que no usan un ramdisk (y en su lugar montansystem.img
directamente).
El significado de una configuración de sistema como raíz difiere entre Android 9 y Android 10. En una configuración de sistema como raíz de Android 9, BOARD_BUILD_SYSTEM_ROOT_IMAGE
se establece en true
, lo que obliga a la compilación a fusionar el sistema de archivos raíz en system.img
y luego monte system.img
como el sistema de archivos raíz (rootfs). Esta configuración es obligatoria para los dispositivos que se inician con Android 9, pero es opcional para los dispositivos que se actualizan a Android 9 y para los dispositivos que ejecutan versiones anteriores de Android. En una configuración de sistema como raíz de Android 10, la compilación siempre fusiona $TARGET_SYSTEM_OUT
y $TARGET_ROOT_OUT
en system.img
; esta configuración es el comportamiento predeterminado para todos los dispositivos que ejecutan Android 10.
Android 10 realiza cambios adicionales para admitir particiones dinámicas , un sistema de partición del espacio de usuario que permite actualizaciones inalámbricas (OTA) para crear, cambiar el tamaño o destruir particiones. Como parte de este cambio, el kernel de Linux ya no puede montar la partición del sistema lógico en dispositivos que ejecutan Android 10, por lo que esta operación la maneja la primera etapa init.
Las siguientes secciones describen los requisitos del sistema como raíz para las OTA solo del sistema, brindan orientación sobre la actualización de dispositivos para usar el sistema como raíz (incluidos los cambios en el diseño de la partición y los requisitos del kernel dm-verity). Para obtener detalles sobre los cambios en ramdisk, consulte Particiones de ramdisk .
Acerca de las OTA solo del sistema
Las OTA solo del sistema, que permiten que las versiones de Android actualicen system.img
y product.img
sin cambiar otras particiones, requieren un diseño de partición del sistema como raíz. Todos los dispositivos que ejecutan Android 10 deben usar un diseño de partición de sistema como raíz para habilitar las OTA solo del sistema.
- Los dispositivos A/B, que montan la partición del
system
como rootfs, ya usan system-as-root y no requieren cambios para admitir las OTA del sistema. - Los dispositivos que no son A/B, que montan la partición del
system
en/system
, deben actualizarse para usar un diseño de partición del sistema como raíz para admitir OTA del sistema.
Para obtener detalles sobre los dispositivos A/B y no A/B, consulte Actualizaciones del sistema A/B (continuas) .
Uso de superposición de proveedores
La superposición de proveedores le permite superponer cambios en la partición del vendor
en el momento del arranque del dispositivo. Una superposición de proveedor es un conjunto de módulos de proveedor en la partición del product
que se superponen en la partición del vendor
cuando se inicia el dispositivo, reemplazando y agregando módulos existentes.
Cuando el dispositivo arranca, el proceso de init
completa el montaje de la primera etapa y lee las propiedades predeterminadas. Luego busca /product/vendor_overlay/<target_vendor_version>
y monta cada subdirectorio en su directorio de partición de vendor
correspondiente, si se cumplen las siguientes condiciones:
-
/vendor/<overlay_dir>
existe. -
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
tiene el mismo contexto de archivo que/vendor/<overlay_dir>
. -
init
puede montarse en el contexto de archivo de/vendor/<overlay_dir>
.
Implementación de superposición de proveedores
Instale archivos de superposición de proveedores en /product/vendor_overlay/<target_vendor_version>
. Esos archivos se superponen a la partición del vendor
cuando se inicia el dispositivo, reemplazando los archivos del mismo nombre y agregando cualquier archivo nuevo. La superposición del proveedor no puede eliminar archivos de la partición del vendor
.
Los archivos de superposición del proveedor deben tener el mismo contexto de archivo que los archivos de destino que reemplazan en la partición del vendor
. De forma predeterminada, los archivos en el /product/vendor_overlay/<target_vendor_version>
tienen el contexto de vendor_file
. Si hay discrepancias en el contexto del archivo entre los archivos superpuestos del proveedor y los archivos que reemplazan, especifíquelo en la política específica del dispositivo. El contexto del archivo se establece en el nivel del directorio. Si el contexto de archivo de un directorio de superposición de proveedor no coincide con el directorio de destino y el contexto de archivo correcto no se especifica en la política específica del dispositivo, ese directorio de superposición de proveedor no se superpone en el directorio de destino.
Para usar la superposición del proveedor, el kernel debe habilitar OverlayFS configurando CONFIG_OVERLAY_FS=y
. Además, el kernel debe fusionarse desde el kernel común 4.4 o posterior, o parchearse con "overlayfs: override_creds=off option bypass creator_cred"
.
Ejemplo de implementación de superposición de proveedores
Este procedimiento demuestra la implementación de una superposición de proveedores que superpone los directorios /vendor/lib/*
, /vendor/etc/*
y /vendor/app/*
.
Agregue archivos de proveedores preconstruidos en
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/
:device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
Instale los archivos de proveedores preconstruidos en
product/vendor_overlay
endevice/google/device/device.mk
:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
Defina contextos de archivo si los archivos de partición de
vendor
de destino tienen contextos distintos devendor_file
. Debido a que/vendor/lib/*
usa el contexto devendor_file
, este ejemplo no incluye ese directorio.Agrega lo siguiente a
device/google/device-sepolicy/private/file_contexts
:/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
Permita que el proceso de
init
monte la superposición del proveedor en contextos de archivo que no seanvendor_file
. Debido a que el proceso deinit
ya tiene permiso para montarse en el contexto devendor_file
, este ejemplo no define la política paravendor_file
.Agrega lo siguiente a
device/google/device-sepolicy/public/init.te
:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
Validación de superposición de proveedores
Para validar la configuración de superposición del proveedor, agregue archivos en /product/vendor_overlay/<target_vendor_version>/<overlay_dir>
y verifique si los archivos están superpuestos en los archivos en /vendor/<overlay_dir>
.
Para compilaciones de userdebug
de usuarios, hay un módulo de prueba para Atest :
$ atest -v fs_mgr_vendor_overlay_test
Actualización al sistema como root
Para actualizar dispositivos que no sean A/B para usar system-as-root, debe actualizar el esquema de partición para boot.img
y system.img
, configurar dm-verity y eliminar cualquier dependencia de arranque en las carpetas raíz específicas del dispositivo.
Actualización de particiones
A diferencia de los dispositivos A/B que reutilizan /boot
como partición de recuperación , los dispositivos que no son A/B deben mantener la partición /recovery
separada, ya que no tienen la partición de ranura de reserva (por ejemplo, de boot_a
a boot_b
). Si /recovery
se elimina en un dispositivo que no es A/B y se hace similar al esquema A/B, el modo de recuperación podría interrumpirse durante una actualización fallida de la partición /boot
. Por esta razón, la partición /recovery
debe ser una partición separada de /boot
para dispositivos que no sean A/B, lo que implica que la imagen de recuperación continuará actualizándose de manera diferida (es decir, igual que en los dispositivos que ejecutan Android). 8.1.0 o inferior).
La siguiente tabla enumera las diferencias de partición de imágenes para dispositivos que no son A/B antes y después de Android 9.
Imagen | Ramdisk (antes de 9) | Sistema como raíz (después de 9) |
---|---|---|
boot.img | Contiene un kernel y un ramdisk.img : ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ... | Contiene solo un kernel de arranque normal. |
recovery.img | Contiene un kernel de recuperación y un ramdisk.img de recuperación. | |
system.img | Contiene lo siguiente: system.img -/ - bin/ - etc - vendor -> /vendor - ... | Contiene el contenido combinado de system.img y ramdisk.img originales: system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ... |
Las particiones en sí no cambian; tanto ramdisk como system-as-root utilizan el siguiente esquema de partición:
-
/boot
-
/system
-
/system
-
/recovery
-
/vendor
, etc
Configuración de dm-verity
En system-as-root, el kernel debe montar system.img
bajo /
(punto de montaje) con dm-verity . AOSP es compatible con las siguientes implementaciones de dm-verity para system.img
.
vboot 1.0
Para vboot 1.0 , el kernel debe analizar los metadatos específicos de Android en /system
y luego convertirlos a parámetros dm-verity para configurar dm-verity (requiere estos parches del kernel ). El siguiente ejemplo muestra la configuración relacionada con dm-verity para system-as-root en la línea de comando del kernel:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
Para vboot 2.0 ( AVB ), el cargador de arranque debe integrar external/avb/libavb , que luego analiza el descriptor hashtree para /system
, lo convierte en parámetros dm-verity y finalmente pasa los parámetros al kernel a través de la línea de comando del kernel. (Los descriptores de hashtree de /system
pueden estar en /vbmeta
o en /system
mismo).
vboot 2.0 requiere los siguientes parches del kernel:
- https://revisión-de-android.googlesource.com/#/c/kernel/common/+/158491/
- parches del kernel 4.4, parches del kernel 4.9 , etc.
El siguiente ejemplo muestra la configuración relacionada con dm-verity para system-as-root en la línea de comando del kernel:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
Uso de carpetas raíz específicas del dispositivo
Con el sistema como raíz, después de que la imagen genérica del sistema (GSI) se muestre en el dispositivo (y antes de ejecutar las pruebas de Vendor Test Suite ), todas las carpetas raíz específicas del dispositivo agregadas con BOARD_ROOT_EXTRA_FOLDERS
desaparecen porque todo el contenido del directorio raíz ha sido reemplazado por el sistema como raíz GSI. La eliminación de estas carpetas puede hacer que el dispositivo no se pueda iniciar si existe una dependencia de las carpetas raíz específicas del dispositivo (por ejemplo, se usan como puntos de montaje).
Para evitar este problema, no utilice BOARD_ROOT_EXTRA_FOLDERS
para agregar carpetas raíz específicas del dispositivo. Si necesita especificar puntos de montaje específicos del dispositivo, use /mnt/vendor/<mount point>
(agregado en estas listas de cambios). Estos puntos de montaje específicos del proveedor se pueden especificar directamente tanto en el árbol de dispositivos fstab
(para el montaje de primera etapa) como en el archivo /vendor/etc/fstab.{ro.hardware}
sin configuración adicional (ya que fs_mgr
los crea en /mnt/vendor/*
automáticamente).