Diseño de partición

En Android 10, el sistema de archivos raíz ya no es se incluye en ramdisk.img y, en su lugar, se combina en system.img (es decir, system.img siempre se crea como si se configuró BOARD_BUILD_SYSTEM_ROOT_IMAGE). Dispositivos que se lanzan con Android 10:

  • Usa un diseño de partición de sistema como raíz (aplicado automáticamente por el sin opciones para cambiar su comportamiento).
  • Se debe usar un ramdisk, que es necesario para dm-linear.
  • Se debe configurar BOARD_BUILD_SYSTEM_ROOT_IMAGE como false. Este parámetro de configuración solo se usa para diferenciar entre dispositivos que usan un disco RAM y los que no usan un disco RAM (y, en su lugar, activan system.img directamente).

El significado de una configuración de sistema como raíz difiere entre Android 9 y Android 10 En un sistema como raíz de Android 9 de Terraform, se establece BOARD_BUILD_SYSTEM_ROOT_IMAGE como true, que fuerza la compilación a combinar el sistema de archivos raíz en Luego, system.img y, luego, activa system.img como archivo raíz. (rootfs). Esta configuración es obligatoria para los dispositivos lanzarse con Android 9, pero es opcional para los dispositivos que se actualizan a Android 9 y para dispositivos que ejecutan versiones anteriores de Android En un dispositivo Android hasta 10 configuraciones system-as-root, la compilación siempre combina $TARGET_SYSTEM_OUT y $TARGET_ROOT_OUT en system.img; esta configuración es el comportamiento predeterminado para todos los dispositivos con Android 10.

Android 10 realiza cambios adicionales en la compatibilidad particiones dinámicas, un sistema de partición del espacio de usuario que permite actualizaciones inalámbricas para crear, cambiar el tamaño o destruir particiones. Como parte de este cambio, la consola de Linux kernel ya no puede activar la partición lógica del sistema en dispositivos que se ejecutan Android 10, por lo que esta operación la controla el primer init de la etapa.

En las siguientes secciones, se describen los requisitos del sistema como raíz para OTA solo para el sistema; proporciona orientación sobre la actualización de dispositivos para usar el sistema como raíz. (incluidos los cambios de diseño de partición y los requisitos del kernel de dm-verity). Para detalles sobre cambios en ramdisk, consulta Ramdisk Particiones.

Información acerca de las OTA solo del sistema

OTA solo para el sistema, que permiten que las versiones de Android se actualicen system.img y product.img sin cambiar otra particiones, requieren un diseño de partición de sistema como raíz. Todos los dispositivos con Android 10 deben usar un diseño de partición de sistema como raíz para habilitar las OTA solo del sistema.

Para obtener detalles sobre dispositivos A/B y que no son A/B, consulta Actualizaciones del sistema A/B (sin problemas).

Usar la superposición de proveedores

La superposición de proveedores te permite superponer los cambios en vendor al iniciar el dispositivo. Una superposición de proveedor es un conjunto de módulos de proveedor en la partición product que se superpone en vendor cuando se inicia el dispositivo, reemplazando y agregando a los módulos existentes.

Cuando se inicia el dispositivo, el proceso init completa la primera la activación de la etapa y lee las propiedades predeterminadas. Luego, busca /product/vendor_overlay/<target_vendor_version> y activaciones cada subdirectorio en el directorio de partición 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>.
  • Se permite activar init en el contexto de archivos de /vendor/<overlay_dir>

Implementar la superposición de proveedores

Instala archivos de superposición de proveedores en /product/vendor_overlay/<target_vendor_version>. Esos archivos superpone la partición vendor cuando se inicie el dispositivo para reemplazar los archivos del mismo nombre y agregando cualquier archivo nuevo. La superposición del proveedor no puede quitar archivos de la partición vendor.

Los archivos de superposición de proveedores deben tener el mismo contexto de archivo que los archivos de destino se reemplazan en la partición vendor. De forma predeterminada, los archivos del Directorio /product/vendor_overlay/<target_vendor_version> tener el contexto vendor_file. Si el contexto de los archivos no coincide entre los archivos de superposición de proveedores y los archivos que reemplazan, especifícalo en la una política específica del dispositivo. El contexto del archivo se establece a nivel del directorio. Si el botón el contexto del archivo de un directorio de superposición de proveedor no coincide con el directorio de destino. y no se especifica el contexto de archivo correcto en la política específica del dispositivo para que el directorio de superposición del proveedor no se superponga en el directorio de destino.

Para usar la superposición de proveedores, el kernel debe habilitar OverlayFS a través de la configuración CONFIG_OVERLAY_FS=y. Además, el kernel debe combinarse desde el kernel común 4.4 o posterior, o con el parche de "overlayfs: override_creds=off option bypass creator_cred".

Ejemplo de implementación de superposiciones de proveedores

Este procedimiento demuestra la implementación de una superposición de proveedor que se superpone a los directorios /vendor/lib/*, /vendor/etc/* y /vendor/app/*

  1. Cómo agregar archivos de proveedores compilados previamente 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

  2. Instala los archivos precompilados del proveedor para product/vendor_overlay in device/google/device/device.mk

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. Define contextos de archivos si los archivos de partición vendor de destino tienen contextos distintos de vendor_file. Porque /vendor/lib/* usa el contexto vendor_file, esta 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

  4. Permitir que el proceso init active la superposición del proveedor en el archivo contextos distintos de vendor_file. Debido a que init ya tiene permiso para activarse en el contexto vendor_file este ejemplo no define la política para vendor_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;

Validar la superposición del proveedor

Para validar la configuración de la superposición de proveedores, agrega archivos en /product/vendor_overlay/<target_vendor_version>/<overlay_dir> y comprobar si los archivos están superpuestos sobre los archivos de /vendor/<overlay_dir>

En las compilaciones de userdebug, hay un módulo de prueba para Atest:

$ atest -v fs_mgr_vendor_overlay_test

Actualiza a system-as-root

Si quieres actualizar dispositivos que no sean A/B para usar system-as-root, debes actualizar el esquema de partición para boot.img y system.img, establecer hacia arriba dm-verity y quita las dependencias de inicio en la raíz específica del dispositivo individuales.

Actualiza particiones

A diferencia de los dispositivos A/B que reutilizan /boot como recovery, Los dispositivos que no sean A/B deben mantener la partición /recovery separadas, ya que no tienen la partición de ranura de resguardo (por ejemplo, de boot_a a boot_b). Si /recovery es el modo de recuperación se elimina en un dispositivo que no es A/B y se hace similar al esquema A/B. podría fallar durante una actualización con errores en la partición /boot. Para por lo que la partición /recovery debe ser un partición separada de /boot para dispositivos que no son A/B, lo que implica que la imagen de recuperación continúe actualizándose de manera aplazada (que es igual a la de los dispositivos con Android 8.1.0 o versiones anteriores).

En la siguiente tabla, se indican las diferencias de partición de imagen para dispositivos que no son A/B antes y después de Android 9.

Imagen Ramdisk (anterior a 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 inicio normal.
recovery.img Contiene un kernel de recuperación y un ramdisk.img.
system.img Contiene lo siguiente: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 Incluye el contenido combinado del system.img original y ramdisk.img 
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 el disco RAM como el sistema como raíz el siguiente esquema de partición:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor, etcétera

Configurar dm-verity

En el sistema como raíz, el kernel debe activar system.img en / (punto de activación) con dm-verity. AOSP admite la siguiente dm-verity para system.img.

vboot 1.0

Para vboot 1.0, el kernel debe analizar Específico para Android metadatos activados /system y, luego, convierte a parámetros de dm-verity para configurar dm-verity (requiere estos parches de kernel). En el siguiente ejemplo, se muestra la configuración relacionada con dm-verity para system-as-root en línea de comandos de 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 bootloader debe integrarse external/avb/libavb, que luego analiza los descriptor de hashtree para /system, convierte a parámetros dm-verity y, por último, los pasa al a través de la línea de comandos del kernel. (Descriptores de Hashtree de /system puede estar en /vbmeta o en /system).

vboot 2.0 requiere los siguientes parches de kernel:

En el siguiente ejemplo, se muestra la configuración relacionada con dm-verity para system-as-root en línea de comandos de 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"

Usa carpetas raíz específicas del dispositivo

Con system-as-root, después de la imagen genérica del sistema (GSI) se instala en el dispositivo (y antes de ejecutar del paquete de pruebas del proveedor), cualquier Carpetas raíz específicas del dispositivo agregadas con BOARD_ROOT_EXTRA_FOLDERS desaparecieron porque todo el contenido del directorio raíz se reemplazó por la GSI de sistema como raíz. La eliminación de estas carpetas puede provocar que el dispositivo no se pueden iniciar si existe una dependencia en las carpetas raíz específicas del dispositivo. (por ejemplo, se usan como puntos de activación).

Para evitar este problema, no uses BOARD_ROOT_EXTRA_FOLDERS para agregar carpetas raíz específicas del dispositivo Si necesitas especificar el soporte específico del dispositivo puntos, usa /mnt/vendor/<mount point> (agregado en estos listas de cambios). Estos puntos de activación específicos del proveedor se pueden especificado directamente en el árbol de dispositivos fstab (para la primera etapa activar) y el archivo /vendor/etc/fstab.{ro.hardware} sin configuración adicional (ya que fs_mgr los crea en /mnt/vendor/* automáticamente).