Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Diseño de partición

En androide 10, el sistema de ficheros raíz ya no se incluye en ramdisk.img y en su lugar se combinó en system.img (es decir, system.img se crea siempre como si BOARD_BUILD_SYSTEM_ROOT_IMAGE ha sido fijado). Dispositivos que se inician con Android 10:

  • Utilice un diseño de partición de sistema como raíz (aplicado automáticamente por la compilación sin opciones para cambiar el comportamiento).
  • Debe utilizar un disco RAM, que es necesario para dm-linear.
  • Debe establecer BOARD_BUILD_SYSTEM_ROOT_IMAGE a false . Este ajuste sólo se utiliza para diferenciar los distintos dispositivos que utilizan un disco de memoria y dispositivos que no utilizan un disco RAM (y en lugar de montar system.img directamente).

El significado de una diferencia de configuración del sistema, como la raíz entre Android y Android 9 10. En un Android 9-configuración del sistema como root, BOARD_BUILD_SYSTEM_ROOT_IMAGE se establece en true , que las fuerzas de la acumulación de fusionar el sistema de ficheros en system.img entonces montar system.img como el sistema de archivos raíz (rootfs). Esta configuración es obligatorio para dispositivos de lanzamiento con Android 9 pero es opcional para los dispositivos de la actualización a Android 9 y para los dispositivos que ejecutan versiones inferiores de Android. En una configuración de Android 10 sistema como root, la acumulación siempre se 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 hace más cambios de apoyo particiones dinámicas , un sistema de separación de espacio de usuario que permite actualizaciones over-the-air (OTA) para crear, cambiar el tamaño, o destruir las 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 el init de la primera etapa.

Las siguientes secciones describen los requisitos del sistema como raíz para las OTA exclusivas 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 las particiones y los requisitos del kernel de dm-verity). Para más detalles sobre los cambios a DISCO RAM, consulte RAMDISK particiones .

Acerca de las OTA exclusivas del sistema

OTA sistema de sólo, que permiten lanzamientos de Android para actualizar system.img y product.img sin cambiar otras particiones, requieren una distribución de la partición del sistema, como root. 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.

Para más detalles sobre A / B y no A / dispositivos B, referirse a A / B (sin soldadura) Actualizaciones del sistema .

Usar superposición de proveedores

Superposición proveedor permite superponer cambios en el vendor de particiones en el arranque del dispositivo. Una superposición vendedor es un conjunto de módulos de proveedor en el product partición que get superpuesto en el vendor partición cuando se inicia el dispositivo, en sustitución y la adición a los módulos existentes.

Cuando se inicia el dispositivo, el init proceso de montaje se completa la primera etapa y lee las propiedades predeterminadas. A continuación, se busca en /product/vendor_overlay/<target_vendor_version> y se monta cada subdirectorio en su correspondiente vendor directorio de partición, si se cumplen las siguientes condiciones:

  • /vendor/<overlay_dir> existe.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> tiene el mismo contexto como archivo /vendor/<overlay_dir> .
  • init se permite montar en el contexto de archivo /vendor/<overlay_dir> .

Implementación de superposición de proveedores

Instalar archivos de superposición de los proveedores en /product/vendor_overlay/<target_vendor_version> . Esos archivos de superposición del vendor partición cuando se inicia el dispositivo, en sustitución de los archivos del mismo nombre y añadir nuevos archivos. Superposición vendedor no puede eliminar archivos de la vendor partición.

Archivos de superposición proveedor deben tener el mismo contexto que los archivos de destino a los que sustituyen en el vendor partición. De manera predeterminada, los archivos de la /product/vendor_overlay/<target_vendor_version> directorio tienen la vendor_file contexto. Si hay discrepancias de contexto de archivo entre los archivos de superposición del proveedor y los archivos que reemplazan, especifíquelo en la política de seguridad específica del dispositivo. El contexto del archivo se establece en el nivel de 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 de seguridad específica del dispositivo, ese directorio de superposición de proveedor no se superpone al directorio de destino.

Para el uso de superposición proveedor, el núcleo debe permitir OverlayFS estableciendo CONFIG_OVERLAY_FS=y . Además, el núcleo debe ser unido desde el núcleo común 4.4 o posterior, o parcheado con "overlayfs: override_creds=off option bypass creator_cred" .

Ejemplo de implementación de superposición de proveedores

Este procedimiento muestra la aplicación de un recubrimiento proveedor que se superpone a la directorios /vendor/lib/* , /vendor/etc/* y /vendor/app/* .

  1. Añadir archivos creados previamente en proveedores 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. Instalar los archivos de proveedores de pre-compilados a product/vendor_overlay en 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. Definir contextos de archivos Si el objetivo vendor archivos de partición tienen contextos distintos vendor_file . Debido /vendor/lib/* usos del vendor_file contexto, este ejemplo no incluye ese directorio.

    Agregue lo siguiente al 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. Deje que el init proceso de montar la superposición vendedor en contextos de archivos distintos de vendor_file . Debido a que el init proceso ya tiene permiso para montar en la vendor_file contexto, este ejemplo no definir la política de vendor_file .

    Agregue lo siguiente al 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 proveedor, añadir archivos en /product/vendor_overlay/<target_vendor_version>/<overlay_dir> y comprobar si los archivos se superponen sobre los archivos en /vendor/<overlay_dir> .

Para userdebug construye, hay un módulo de prueba para Atest :

$ atest -v fs_mgr_vendor_overlay_test

Actualización a sistema como root

Para actualizar los dispositivos no-A / B para el uso del sistema, como root, debe actualizar el esquema de partición para boot.img y system.img , configurar DM-Verity, y quitar cualquier dependencia de arranque en las carpetas raíz específicos del dispositivo.

Actualizar particiones

A diferencia de A / B que dispositivos repurpose /boot como la recuperación de partición, no A / dispositivos B deben mantener el /recovery partición separada, ya que no tienen la partición de la ranura de retorno (por ejemplo, de boot_a a boot_b ). Si /recovery se elimina en la no-dispositivo A / B y hecho similar al esquema A / B, modo de recuperación podría romperse durante una actualización fallida a la /boot partición. Por esta razón, la /recovery partición debe ser una partición separada de /boot para los dispositivos no-A / B, lo que implica que la imagen de recuperación continuará siendo actualizado de manera diferida (es decir, el mismo que en los dispositivos con Android 8.1.0 o inferior).

La siguiente tabla enumera las diferencias de partición de imágenes para dispositivos no A / B antes y después de Android 9.

Imagen Ramdisk (antes de las 9) Sistema como root (después de 9)
boot.img Contiene un núcleo y una ramdisk.img :
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
Solo contiene un kernel de arranque normal.
recovery.img Contiene un núcleo de recuperación y una recuperación ramdisk.img .
system.img Contiene los siguientes:
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
Contiene el contenido resultante de la fusión de originales system.img 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í mismas 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 el sistema-como-raíz, el núcleo debe montar system.img bajo / (punto de montaje) con dm-Verity . AOSP soporta los siguientes implementaciones dm-Verity para system.img .

vboot 1.0

Para Vboot 1.0 , el kernel debe analizar Android específica metadatos en /system , a continuación, convertir a DM-Verity parametros 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 comandos 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 ( BAV ), el cargador de arranque debe integrar externo / avb / libavb , que a continuación analiza el descriptor hashtree para /system , lo convierte a DM-Verity params , y finalmente pasa los params al núcleo a través de la línea de comandos del núcleo. (Descriptores Hashtree de /system podrían estar en /vbmeta o en /system sí mismo.)

vboot 2.0 requiere los siguientes parches del kernel:

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

Usar carpetas raíz específicas del dispositivo

Con sistema como root, después de que la imagen del sistema genérico (GSI) se lanzó en el dispositivo (y antes de ejecutar Vendedor Conjunto de pruebas de pruebas), ninguna carpeta raíz del dispositivo específicas añadidas con BOARD_ROOT_EXTRA_FOLDERS se han ido porque todo el contenido del directorio raíz se ha reemplazado por el GSI del sistema como raíz. La eliminación de estas carpetas puede hacer que el dispositivo no se pueda iniciar si existe una dependencia en las carpetas raíz específicas del dispositivo (por ejemplo, se utilizan como puntos de montaje).

Para evitar este problema, no utilice BOARD_ROOT_EXTRA_FOLDERS añadir carpetas raíz específicos del dispositivo. Si es necesario especificar el montaje del dispositivo específico puntos, el uso /mnt/vendor/<mount point> (añadido en estas listas de cambios ). Estos montaje específica del proveedor puntos se pueden especificar directamente tanto en el fstab árbol de dispositivos (para la primera etapa de montaje) y el /vendor/etc/fstab.{ro.hardware} archivo sin configuración adicional (como fs_mgr les crea bajo /mnt/vendor/* automáticamente).