Los dispositivos Android incluyen varias particiones que cumplen diferentes funciones en el proceso de arranque.
Particiones estándar
partición
boot
. Esta partición contiene una imagen del kernel y se crea usandomkbootimg
. Puede usar una partición virtual para actualizar cualquier imagen directamente sin actualizar una nueva partición de arranque. Esta partición también contiene el ramdisk genérico en dispositivos lanzados antes de Android 13.núcleo. La partición del
kernel
virtual sobrescribe el kernel (zImage
, zImage-zImage-dtb
,Image.gz-dtb
) al escribir la nueva imagen del kernel sobre la imagen del kernel anterior. Si el kernel de desarrollo proporcionado es incompatible, es posible que deba actualizar la partición delvendor
, elsystem
odtb
(si está presente) con los módulos del kernel asociados.ramdisk La partición
ramdisk
virtual sobrescribe el ramdisk escribiendo la nueva imagen ramdisk sobre la imagen ramdisk antigua.
La operación de sobrescritura determina la ubicación de inicio de la imagen existente en eMMC y copia la nueva imagen en esa ubicación. La nueva imagen (kernel o ramdisk) puede ser más grande que la existente; para hacer espacio, el gestor de arranque puede mover datos siguiendo la imagen o abandonar la operación con un error.
partición
init_boot
. Esta partición contiene el ramdisk genérico para dispositivos que se inician con Android 13 y versiones posteriores.partición
system
. Esta partición contiene el marco de Android.partición
odm
. Esta partición contiene personalizaciones del fabricante de diseño original (ODM) para paquetes de soporte de placa de proveedor (BSP) de sistema en chip (SoC). Dichas personalizaciones permiten que los ODM reemplacen o personalicen los componentes de SoC e implementen módulos kernel para componentes específicos de placa, demonios y características específicas de ODM en capas de abstracción de hardware (HAL). Esta partición es opcional; por lo general, se usa para contener personalizaciones para que los dispositivos puedan usar una sola imagen de proveedor para múltiples SKU de hardware. Para obtener más información, consulte Particiones ODM .partición
odm_dlkm
. Esta partición está dedicada a almacenar módulos de kernel ODM. El almacenamiento de módulos del kernel ODM en la particiónodm_dlkm
(a diferencia de la particiónodm
) hace posible actualizar los módulos del kernel ODM sin actualizar la particiónodm
.partición de
recovery
. Esta partición almacena la imagen de recuperación, que se inicia durante el proceso OTA. Los dispositivos que admiten actualizaciones transparentes pueden almacenar las imágenes de recuperación como un ramdisk contenido en la imagen deboot
oinit_boot
(en lugar de una imagen separada).partición
cache
. Esta partición almacena datos temporales y es opcional si un dispositivo utiliza actualizaciones continuas. No es necesario que la partición de caché se pueda escribir desde el cargador de arranque, pero sí se debe poder borrar. El tamaño de la partición depende del tipo de dispositivo y la disponibilidad de espacio en los datos deuserdata
; normalmente, 50 MB–100 MB es suficiente.partición
misc
. Esta partición es utilizada por la partición de recuperación y tiene 4 KB o más.partición
userdata
. Esta partición contiene aplicaciones y datos instalados por el usuario, incluidos datos de personalización.partición
metadata
. Esta partición se utiliza para almacenar la clave de cifrado de metadatos cuando el dispositivo utiliza cifrado de metadatos . El tamaño es de 16 MB o más grande. No está encriptado y sus datos no se capturan instantáneamente. Se borra cuando el dispositivo se restablece de fábrica. El uso de esta partición está estrictamente limitado.partición
vendor
. Esta partición contiene cualquier binario que no se pueda distribuir a AOSP. Si el dispositivo no contiene información de propiedad, puede omitir esta partición.partición
vendor_dlkm
. Esta partición está dedicada a almacenar módulos de kernel de proveedores. El almacenamiento de los módulos del kernel del proveedor en la particiónvendor_dlkm
(a diferencia de la partición delvendor
) hace posible actualizar los módulos del kernel sin actualizar la partición delvendor
.partición
radio
. Esta partición contiene la imagen de radio y solo se necesita para dispositivos que incluyen una radio con software específico de radio en una partición dedicada.partición
tos
. Esta partición almacena la imagen binaria del sistema operativo Trusty y se usa solo si el dispositivo incluye Trusty. Para obtener más información, consulte Particiones TOS .
Particiones dinámicas
Los dispositivos que ejecutan Android 11 y versiones posteriores pueden admitir particiones dinámicas, que son un sistema de partición del espacio de usuario para Android que permite crear, cambiar el tamaño o destruir particiones durante las actualizaciones inalámbricas (OTA). Para obtener más información, consulte Particiones dinámicas .
Designación de particiones críticas
Si el dispositivo requiere particiones o datos específicos para ejecutarse, debe designar esas particiones/datos como totalmente protegidos o como re-flasheables, lo que significa que se pueden reconstruir, proporcionar o extraer mediante un comando fastboot oem
. Esto incluye datos como configuraciones específicas de fábrica por dispositivo, números de serie, datos de calibración y más.
Cambios en Android 11
Android 11 incluye numerosos cambios en las particiones, incluidas restricciones en la vinculación a bibliotecas y nuevas variantes de imágenes de Soong.
Figura 1. Diseño de partición en Android 11
Imagen de sistema único (SSI). Una nueva imagen conceptual que contiene las imágenes
system
ysystem_ext
. Cuando estas particiones son comunes para un conjunto de dispositivos de destino, esos dispositivos pueden compartir el SSI y omitir la creación delsystem
y las imágenessystem_ext
.partición
system_ext
. Una nueva partición que puede usar los recursossystem
y puede incluir módulos del sistema que:Extienda los módulos del sistema AOSP en la partición del
system
. Recomendamos subir dichos módulos a AOSP para que puedan instalarse en la partición delsystem
más tarde.Agrupe módulos OEM o específicos de SoC. Recomendamos desagregar dichos módulos para que puedan instalarse en la partición del
product
ovendor
.
partición
system
. Imagen de sistema común utilizada para productos OEM. Recomendamos mover los módulos propietarios fuera de la partición delsystem
, ya sea subiéndolos a AOSP o moviéndolos a la particiónsystem_ext
.partición de
product
. Esta partición ahora puede usar interfaces permitidas para instalar módulos específicos del producto que no se incluyen con ninguna otra partición.
Cambios de VNDK
El Vendor Native Development Kit (VNDK) es un conjunto de bibliotecas instaladas en la partición del system
y diseñadas exclusivamente para que los proveedores implementen sus HAL.
En Android 10 y versiones anteriores, la partición del
vendor
puede vincularse a bibliotecas VNDK en la partición delsystem
, pero no puede vincularse a otras bibliotecas en la partición delsystem
. Los módulos nativos en la partición delproduct
pueden vincularse a cualquier biblioteca en la partición delsystem
.En Android 11 y versiones posteriores, las particiones de
product
yvendor
pueden vincularse a bibliotecas VNDK en la partición delsystem
, pero no pueden vincularse a otras bibliotecas en la partición delsystem
.
Variantes de productos pronto
El sistema de compilación de Soong usa variantes de imágenes para dividir las dependencias de compilación. Los módulos nativos ( /build/soong/cc
) pueden mutar los módulos de proceso del sistema a la variante principal y los módulos de proceso del proveedor a la variante del proveedor; un módulo en una variante de imagen no puede vincularse a otros módulos en una variante de imagen diferente.
En Android 10 o versiones anteriores, un módulo del sistema crea automáticamente variantes principales. También puede crear variantes de proveedores definiendo
vendor_available: true
en sus archivosAndroid.bp
; esto permite que los módulos del proveedor se vinculen con los módulos del sistema. Las bibliotecas de VNDK, que son variantes de proveedores de las bibliotecas delsystem
, también pueden crear variantes de proveedores para módulos de proveedores definiendovendor_available: true
en sus archivosAndroid.bp
(consulte el ejemplo ).En Android 11, un módulo del sistema también puede crear una variante de producto (además de las variantes principales y de proveedor) definiendo
vendor_available: true
.En Android 12 o superior, un módulo del sistema con
vendor_available: true
crea una variante de proveedor además de la variante principal. Para crear una variante de producto, debe definirseproduct_available: true
. Algunas bibliotecas de VNDK sinproduct_available: true
no están disponibles para los módulos de productos.