A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

Se usó la API de Cloud Translation para traducir esta página.

Diseño de particiones
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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

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

El significado de una configuración del 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 combinar el sistema de archivos raíz en system.img y, luego, activar 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 combina $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 más cambios para admitir particiones dinámicas, un sistema de partición de espacio de usuario que permite que las actualizaciones inalámbricas (OTA) creen, cambien el tamaño o destruyan particiones. Como parte de este cambio, el kernel de Linux ya no puede activar la partición del sistema lógico en dispositivos que ejecutan Android 10, por lo que la primera etapa de init controla esta operación.

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

Información acerca de las actualizaciones OTA solo del sistema

Las actualizaciones 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 de sistema como raíz. Todos los dispositivos que ejecutan Android 10 deben usar un diseño de partición del sistema como raíz para habilitar las actualizaciones OTA solo del sistema.

Los dispositivos A/B, que activan la partición system como rootfs, ya usan system-as-root y no requieren cambios para admitir OTA del sistema.
Los dispositivos que no son A/B, que montan la partición system en /system, deben actualizarse para usar un diseño de partición system-as-root para admitir actualizaciones OTA del sistema.

Para obtener detalles sobre los dispositivos A/B y no A/B, consulta Actualizaciones del sistema A/B (sin interrupciones).

Usa la superposición del proveedor (<=AOSP 14)

La superposición del proveedor te permite superponer cambios en la partición vendor durante el inicio del dispositivo. Una superposición del proveedor es un conjunto de módulos del proveedor en la partición product que se superponen en la partición vendor cuando se inicia el dispositivo, reemplazando y agregando los módulos existentes.

Cuando se inicia el dispositivo, el proceso init completa el primer montaje de etapa y lee las propiedades predeterminadas. Luego, busca /product/vendor_overlay/<target_vendor_version> y activa cada subdirectorio en su 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>.
init se puede activar en el contexto de archivo de /vendor/<overlay_dir>.

Implementa la superposición del proveedor

Instala archivos de superposición del proveedor en /product/vendor_overlay/<target_vendor_version>. Esos archivos superponen la partición vendor cuando se inicia el dispositivo, reemplazan los archivos del mismo nombre y agregan archivos nuevos. La superposición del proveedor no puede quitar archivos de la partición vendor.

Los archivos superpuestos del proveedor deben tener el mismo contexto de archivo que los archivos de destino que reemplazan en la partición vendor. De forma predeterminada, los archivos del directorio /product/vendor_overlay/<target_vendor_version> tienen el contexto vendor_file. Si hay discrepancias de contexto de archivos entre los archivos de superposición del proveedor y los archivos que reemplazan, especifícalo en la política de SE específica del dispositivo. El contexto de archivo se establece a nivel del directorio. Si el contexto de 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 de SE 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 se debe combinar desde el kernel común 4.4 o una versión posterior, o bien parchearse con "overlayfs: override_creds=off option bypass creator_cred".

Ejemplo de implementación de la superposición del proveedor

En este procedimiento, se muestra la implementación de una superposición de proveedores que superpone los directorios /vendor/lib/*, /vendor/etc/* y /vendor/app/*.

Agrega 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

Instala los archivos del proveedor precompilados en 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)

Define los contextos de archivo si los archivos de partición vendor de destino tienen contextos distintos de vendor_file. Como /vendor/lib/* usa el contexto vendor_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
```
Permite que el proceso init active la superposición del proveedor en contextos de archivos que no sean vendor_file. Como el proceso 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;
```

Valida la superposición del proveedor

Para validar la configuración de superposición del proveedor, agrega archivos en /product/vendor_overlay/<target_vendor_version>/<overlay_dir> y verifica si se superponen con los archivos de /vendor/<overlay_dir>.

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

$ atest -v fs_mgr_vendor_overlay_test

Actualiza a system-as-root

Para actualizar los dispositivos que no son A/B para que usen el sistema como raíz, debes actualizar el esquema de particionamiento para boot.img y system.img, configurar dm-verity y quitar las dependencias de inicio en las carpetas raíz específicas del dispositivo.

Actualiza las particiones

A diferencia de los dispositivos A/B que reutilizan /boot como la 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 resguardo (por ejemplo, de boot_a a boot_b). Si se quita /recovery en un dispositivo que no es A/B y se hace similar al esquema A/B, el modo de recuperación podría fallar durante una actualización fallida de la partición /boot. Por este motivo, la partición /recovery debe ser una partición independiente de /boot para dispositivos que no sean A/B, lo que implica que la imagen de recuperación se seguirá actualizando de forma diferida (es decir, lo mismo que en dispositivos que ejecutan Android 8.1.0 o versiones anteriores).

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

Imagen	Ramdisk (antes de la versión 9)	System-as-root (después de la versión 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) ...	Solo contiene un kernel de inicio 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 el ramdisk como el sistema como raíz usan el siguiente esquema de partición:

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

Configura dm-verity

En el sistema como raíz, el kernel debe activar system.img en / (punto de activación) con dm-verity. AOSP admite 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 en parámetros de dm-verity para configurar dm-verity (requiere estos parches del kernel). En el siguiente ejemplo, se muestra la configuración relacionada con dm-verity para el sistema como raíz 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 (AVB), el bootloader debe integrar external/avb/libavb, que luego analiza el descriptor hashtree para /system, lo convierte en parámetros de dm-verity y, por último, pasa los parámetros al kernel a través de la línea de comandos del kernel. (Los descriptores de Hashtree de /system pueden 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 el sistema como raíz 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"

Usa carpetas raíz específicas del dispositivo

Con el sistema como raíz, después de que se borre la imagen genérica del sistema (GSI) en el dispositivo (y antes de ejecutar las pruebas del Conjunto de pruebas del proveedor), todas las carpetas raíz específicas del dispositivo que se agregaron con BOARD_ROOT_EXTRA_FOLDERS desaparecerán porque todo el contenido del directorio raíz se reemplazó por la GSI del sistema como raíz. Si quitas estas carpetas, es posible que el dispositivo no se pueda iniciar si existe una dependencia en las carpetas raíz específicas del dispositivo (por ejemplo, si 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 puntos de activación específicos del dispositivo, usa /mnt/vendor/<mount point> (se agregó en estas listas de cambios). Estos puntos de activación específicos del proveedor se pueden especificar directamente en el árbol de dispositivos fstab (para la activación de primera etapa) y en el archivo /vendor/etc/fstab.{ro.hardware} sin configuración adicional (ya que fs_mgr los crea automáticamente en /mnt/vendor/*).