Vista general

Los dispositivos Android incluyen varias particiones que cumplen diferentes funciones en el proceso de arranque.

Particiones estándar

Nota: Los dispositivos que admiten actualizaciones fluidas necesitan una ranura por partición para boot , system , vendor y radio .

• partición boot . Esta partición contiene una imagen del kernel y se crea usando mkbootimg . Puede utilizar una partición virtual para actualizar cualquiera de las imágenes directamente sin necesidad de actualizar una nueva partición de inicio. Esta partición también contiene el disco ram genérico en dispositivos lanzados antes de Android 13.

  • núcleo. La partición virtual kernel sobrescribe el kernel ( zImage , zImage-dtb , Image.gz-dtb ) escribiendo la nueva imagen del kernel sobre la imagen anterior del kernel. Si el kernel de desarrollo proporcionado es incompatible, es posible que deba actualizar la partición vendor , system o dtb (si está presente) con los módulos del kernel asociados.

  • disco RAM. La partición ramdisk virtual sobrescribe el disco ram escribiendo la nueva imagen del disco ram sobre la imagen del disco ram anterior.

  La operación de sobrescritura determina la ubicación inicial 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 ganar 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 disco ram 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 del proveedor (BSP) de sistema en chip (SoC). Dichas personalizaciones permiten a los ODM reemplazar o personalizar componentes de SoC e implementar módulos del kernel para componentes específicos de la 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 única 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 del 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 recovery . Esta partición almacena la imagen de recuperación, que se inicia durante el proceso OTA. Los dispositivos que admiten actualizaciones fluidas pueden almacenar las imágenes de recuperación como un disco RAM contenido en la imagen 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 integradas. No es necesario que se pueda escribir en la partición de caché desde el gestor de arranque, pero sí que se pueda borrar. El tamaño de la partición depende del tipo de dispositivo y de la disponibilidad de espacio en userdata ; normalmente, entre 50 MB y 100 MB son suficientes.

• 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. No está cifrado y sus datos no se capturan. 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 exclusiva, puede omitir esta partición.

• partición vendor_dlkm . Esta partición está dedicada a almacenar módulos del kernel del proveedor. Almacenar los módulos del kernel del proveedor en la partición vendor_dlkm (a diferencia de la partición vendor ) hace posible actualizar los módulos del kernel sin actualizar la partición vendor .

• partición radio . Esta partición contiene la imagen de radio y solo es necesaria para dispositivos que incluyen una radio con software específico de radio en una partición dedicada.

• tos partición. Esta partición almacena la imagen binaria del Trusty OS y se utiliza sólo si el dispositivo incluye Trusty. Para obtener más información, consulte Particiones TOS .

• partición pvmfw . Esta partición almacena el firmware de la máquina virtual protegida (pvmfw), que es el primer código que se ejecuta en las máquinas virtuales protegidas. Consulte Firmware de máquina virtual protegida para obtener más detalles.

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 completamente protegidos o actualizables, 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 para vincular 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 de las imágenes system_ext .

• partición system_ext . Una nueva partición que puede utilizar recursos system y puede incluir módulos del sistema que:

  • Amplíe los módulos del sistema AOSP en la partición system . Recomendamos actualizar dichos módulos a AOSP para que puedan instalarse en la partición system más adelante.

  • 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 sacar los módulos propietarios de la partición system , ya sea transfiriéndolos a AOSP o moviéndolos a la partición system_ext .

• partición product . Esta partición ahora puede usar interfaces permitidas para instalar módulos específicos del producto que no están incluidos con ninguna otra partición.

cambios en VNDK

El Vendor Native Development Kit (VNDK) es un conjunto de bibliotecas instaladas en la partición system y diseñadas exclusivamente para que los proveedores implementen sus HAL.

• En Android 10 y versiones anteriores, la partición vendor puede vincularse a bibliotecas VNDK en la partición system , pero no puede vincularse a otras bibliotecas en la partición system . Los módulos nativos en la partición product pueden vincularse a cualquier biblioteca en la partición system .

• En Android 11 y versiones posteriores, las particiones 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 system .

Próximas variantes del producto

El sistema de compilación de Soong utiliza variantes de imágenes para dividir las dependencias de compilación. Los módulos nativos ( /build/soong/cc ) pueden transformar los módulos de proceso del sistema en la variante principal y los módulos de proceso del proveedor en 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 proveedor 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 VNDK, que son variantes de proveedor de las bibliotecas system , también pueden crear variantes de proveedor para módulos de proveedor definiendo vendor_available: true en sus archivos Android.bp (ver 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, se debe definir product_available: true . Algunas bibliotecas VNDK sin product_available: true no están disponibles para los módulos del producto.