Descripción general

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 usando mkbootimg . 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 del vendor , el system o dtb (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ón odm_dlkm (a diferencia de la partición odm ) hace posible actualizar los módulos del kernel ODM sin actualizar la partición odm .

• 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 de boot o init_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 de userdata ; 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ón vendor_dlkm (a diferencia de la partición del vendor ) hace posible actualizar los módulos del kernel sin actualizar la partición del vendor .

• 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 y system_ext . Cuando estas particiones son comunes para un conjunto de dispositivos de destino, esos dispositivos pueden compartir el SSI y omitir la creación del system y las imágenes system_ext .

• partición system_ext . Una nueva partición que puede usar los recursos system 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 del system 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 o vendor .

• partición system . Imagen de sistema común utilizada para productos OEM. Recomendamos mover los módulos propietarios fuera de la partición del system , ya sea subiéndolos a AOSP o moviéndolos a la partición system_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 del system , pero no puede vincularse a otras bibliotecas en la partición del system . Los módulos nativos en la partición del product pueden vincularse a cualquier biblioteca en la partición del system .

• En Android 11 y versiones posteriores, las particiones de product y vendor pueden vincularse a bibliotecas VNDK en la partición del system , pero no pueden vincularse a otras bibliotecas en la partición del system .

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 archivos Android.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 del system , también pueden crear variantes de proveedores para módulos de proveedores definiendo vendor_available: true en sus archivos Android.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 definirse product_available: true . Algunas bibliotecas de VNDK sin product_available: true no están disponibles para los módulos de productos.