Descripción general

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

Particiones estándar

• Partición boot Esta partición contiene una imagen de kernel y se crea con mkbootimg. Puedes usar una partición virtual para escribir directamente cualquier imagen en la memoria flash sin escribir una nueva partición de inicio en la memoria flash. Esta partición también contiene el disco RAM genérico en dispositivos lanzados antes de Android 13.

  • kernel. La partición virtual kernel reemplaza el kernel (zImage, zImage-dtb, Image.gz-dtb) y escribe la imagen del kernel nueva sobre la anterior. Si el kernel de desarrollo proporcionado no es compatible, es posible que debas actualizar la partición vendor, system o dtb (si está presente) con los módulos de kernel asociados.

  • ramdisk. La partición ramdisk virtual reemplaza el ramdisk escribiendo la nueva imagen de ramdisk sobre la imagen anterior.

  La operación de reemplazo determina la ubicación de inicio de la imagen existente en la eMMC y copia la imagen nueva en esa ubicación. La imagen nueva (kernel o ramdisk) puede ser más grande que la existente. Para liberar espacio, el bootloader puede mover los datos después de 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 framework de Android.

• Partición odm Esta partición contiene personalizaciones del fabricante de diseño original (ODM) para los paquetes de asistencia de placa (BSP) del proveedor del sistema en chip (SoC). Estas personalizaciones permiten que los ODM reemplacen o personalicen componentes del SoC, y que implementen módulos de kernel para componentes específicos de la placa, daemons y funciones 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, de modo que los dispositivos puedan usar una sola imagen de proveedor para varios SKU de hardware. Para obtener más información, consulta Particiones de ODM.

• Partición odm_dlkm Esta partición se dedica a almacenar módulos del kernel de ODM. Almacenar módulos de kernel de ODM en la partición odm_dlkm (en lugar de la partición odm) permite actualizar los módulos de kernel de 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 de actualización OTA. Los dispositivos que admiten actualizaciones sin inconvenientes pueden almacenar las imágenes de recuperación como un ramdisk contenido en la imagen boot o init_boot (en lugar de una imagen independiente).

• Partición cache Esta partición almacena datos temporales y es opcional si un dispositivo usa actualizaciones fluidas. No es necesario que se pueda escribir la partición de caché desde el bootloader, pero sí se debe borrar. El tamaño de la partición depende del tipo de dispositivo y de la disponibilidad de espacio en userdata. Por lo general, es suficiente con entre 50 MB y 100 MB.

• Partición misc La partición de recuperación usa esta partición, que es de 4 KB o más.

• Partición userdata Esta partición contiene apps y datos instalados por el usuario, incluidos los datos de personalización.

• Partición metadata Esta partición se usa para almacenar la clave de encriptación de metadatos cuando el dispositivo usa encriptación de metadatos. El tamaño es de 16 MB como mínimo. No está encriptado y no se crea una instantánea de sus datos. Se borra cuando se restablece la configuración de fábrica del dispositivo. El uso de esta partición está limitado de forma estricta.

• Partición vendor. Esta partición contiene cualquier objeto binario que no se pueda distribuir a AOSP. Si el dispositivo no contiene información propietaria, puedes omitir esta partición.

• Partición vendor_dlkm Esta partición se dedica a almacenar los módulos del kernel del proveedor. Almacenar los módulos de kernel del proveedor en la partición vendor_dlkm (a diferencia de la partición vendor) permite actualizar módulos de kernel sin actualizar la partición vendor.

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

• Partición tos Esta partición almacena la imagen binaria del SO Trusty y solo se usa si el dispositivo incluye Trusty. Para obtener más información, consulta Particiones de las Condiciones del Servicio.

• 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 VMs protegidas. Consulta 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, consulta Particiones dinámicas.

Designa particiones críticas

Si el dispositivo requiere particiones o datos específicos para ejecutarse, debes designar esos particiones o datos como completamente protegidos o como reactualizables, lo que significa que se pueden volver a compilar, proporcionar o extraer con un comando fastboot oem. Esto incluye datos como la configuración específica de fábrica por dispositivo, números de serie, datos de calibración y mucho 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 particiones en Android 11

• Imagen del sistema única (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 compilación de las imágenes system y system_ext.

• Partición system_ext Una partición nueva que puede usar recursos system y puede incluir módulos del sistema que hacen lo siguiente:

  • Extiende los módulos del sistema de AOSP en la partición system. Te recomendamos que envíes esos módulos a AOSP para que se puedan instalar en la partición system más adelante.

  • Agrupa módulos específicos del OEM o del SoC. Te recomendamos que desvincules esos módulos para que se puedan instalar en la partición product o vendor.

• Partición system. Imagen del sistema común que se usa para los productos del OEM. Te recomendamos que quites los módulos propietarios de la partición system, ya sea que los envíes a AOSP o los muevas 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 agrupados con ninguna otra partición.

Cambios en VNDK

El kit de desarrollo nativo del proveedor (VNDK) es un conjunto de bibliotecas instaladas en la partición system y diseñado exclusivamente para que los proveedores implementen sus HAL.

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

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

Variantes de productos de Soong

El sistema de compilación de Soong usa variantes de imagen 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, lo que permite que los módulos de proveedores se vinculen a los módulos del sistema. Las bibliotecas del VNDK, que son variantes del proveedor de las bibliotecas system, también pueden crear variantes del proveedor para los módulos del proveedor definiendo vendor_available: true en sus archivos Android.bp (consulta 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 del proveedor) si se define vendor_available: true.

• En Android 12 y versiones posteriores, un módulo del sistema con vendor_available: true crea una variante del proveedor además de la variante principal. Para crear una variante de producto, se debe definir product_available: true. Algunas bibliotecas de VNDK sin product_available: true no están disponibles para los módulos de productos.