En Android, el almacenamiento interno se divide en particiones, es decir, bloques lógicos que contienen imágenes de software (IMG) con funciones muy concretas. No todo es «espacio para tus fotos»: una parte importante está reservada a arrancar el sistema y a hacer que el hardware funcione como debe.
La arquitectura moderna de Android (a partir de Treble) separa el código genérico del sistema del código dependiente del fabricante en tres grandes grupos: particiones del sistema (por ejemplo, system, boot, init_boot), particiones del proveedor (como vendor, vendor_boot, odm) y particiones no actualizables (userdata, cache, metadata). Esta separación se coordina a través de una interfaz estable llamada VINTF que permite actualizar el sistema sin tocar el código específico del hardware.
Para qué sirven exactamente boot, system y vendor
Las tres protagonistas de esta guía son el corazón del sistema: definen cómo arranca Android, dónde vive el framework y dónde se alojan los binarios del hardware. Comprender sus funciones evita errores al flashear y te da criterio a la hora de actualizar.
Partición boot
La partición boot contiene la imagen de arranque con el kernel. En Android 11 se introduce la GKI (Generic Kernel Image), que estandariza el kernel y desplaza a vendor_boot la información y el ramdisk específicos del proveedor. En Android 12 aún puedes encontrar el ramdisk genérico en boot, pero desde Android 13 ese ramdisk genérico se mueve a init_boot. Esta evolución hace que el kernel sea más genérico y el código dependiente del hardware quede encapsulado donde toca.
Importante para flasheos: si borras boot sin flashear una imagen válida, el dispositivo no arrancará. Y si usas GKI, recuerda que boot y system_dlkm deben actualizarse de forma conjunta por sus dependencias estrechas.
Partición system
system alberga el sistema operativo como tal: framework de Android, apps del sistema y bibliotecas comunes. Desde Android 10-11 se complementa con system_ext (recursos y módulos propietarios que amplían la imagen común) y con product (módulos específicos de producto). Existe un conjunto de reglas de enlace: VNDK (Vendor Native Development Kit), instalado en system, al que pueden vincular product y vendor sin tocar otras bibliotecas de system. Esta separación mantiene ABI estables y permite, en algunos casos, actualizar product por separado si todas las interfaces son estables.
Ojo al «wipe system»: borrar system elimina el sistema operativo. El teléfono puede encender el bootloader o recovery, pero no iniciará Android hasta que flashees una ROM válida.
Partición vendor
vendor contiene binarios, HALs y librerías específicas del hardware que no son lo bastante genéricas para AOSP: drivers del SoC, daemons, módulos de kernel del proveedor (si no se externalizan a vendor_dlkm) y personalizaciones ligadas a la placa. Con Treble, system y vendor intercambian solo a través de VINTF, lo que reduce la rotura de compatibilidad en actualizaciones del sistema.
Extensiones clave: vendor_dlkm permite actualizar módulos del kernel del proveedor sin tocar la partición vendor. Por su parte, odm y odm_dlkm guardan personalizaciones del fabricante de diseño original (ODM) para apoyar múltiples SKUs con una sola imagen de vendor.
Otras particiones relevantes que verás en Android
Además de las protagonistas, hay un buen puñado de particiones que completan el puzle. Conocerlas te aclara mensajes de recovery, OTA y herramientas de flasheo.
- Del sistema:
init_boot(ramdisk genérico desde Android 13),system_ext(extiendesystem),system_dlkm(módulos de GKI),product(módulos de producto),pvmfw(firmware de máquina virtual protegida),generic_bootloader(cargador genérico). - Del proveedor:
vendor_boot(código de arranque del proveedor y ramdisks del proveedor),recovery(imagen de recuperación, que en A/B puede ir como ramdisk enboot/init_boot),misc(usada por recovery, suele ser muy pequeña),vbmeta(metadatos de Verified Boot),vendor,vendor_dlkm,odm,odm_dlkm,radio(firmware de radio si aplica). - No actualizables:
cache(temporal; en A/B a veces es prescindible),userdata(apps y datos del usuario),metadata(clave de cifrado de metadatos si se usa; se borra en factory reset).
Dispositivos con actualizaciones fluidas (A/B): mantienen dos ranuras (A y B) para boot, system, vendor y radio, facilitando OTA sin interrupciones. Las imágenes se aplican en la ranura inactiva y se alterna al reiniciar.
Reglas de actualización y dependencias entre particiones
Actualizar por conjuntos coherentes evita roturas de compatibilidad. Se recomienda actualizar en bloque todas las particiones del sistema y, por separado, todas las del proveedor, verificando que las interfaces entre imágenes permanezcan estables.
Dependencias ineludibles: siempre actualiza conjuntamente boot y system_dlkm, así como init_boot, system, system_ext y product. Si todas las interfaces entre product y el resto del sistema tienen ABI estable, product puede actualizarse de forma independiente.
Verified Boot y vbmeta: la partición vbmeta incluye la información de arranque verificado que asegura la integridad de todas las particiones firmadas. Si algo no cuadra, el dispositivo puede negarse a cargar esa imagen.
Particiones dinámicas: más flexibilidad en OTA
Desde Android 11, muchos dispositivos soportan particiones dinámicas, un sistema de particiones de espacio de usuario que permite crear, redimensionar o destruir particiones durante una OTA sin reflashear toda la tabla. Esto hace más ágiles las actualizaciones y mejora el aprovechamiento del espacio.
Ventaja práctica: el fabricante puede ajustar tamaños de system/product/vendor según evoluciona el software, sin cambios destructivos del esquema de particionado.
