A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los dispositivos Android contienen varias particiones o secciones específicas de espacio de almacenamiento que se usan para contener partes específicas del software del dispositivo. Cada partición contiene una imagen de partición (un archivo IMG) o una instantánea de todo el software de la partición. En la figura 1, se muestra el diseño de las particiones principales en un dispositivo:
Figura 1: Diseño de las particiones centrales.
Las particiones se clasifican en tres categorías:
Las particiones del sistema son las que se actualizan cuando se actualiza el SO y otras funciones. system, boot y init_boot son particiones principales del sistema.
Las particiones del proveedor contienen código específico del dispositivo y el hardware que tal vez nunca se actualice después del lanzamiento inicial. Las particiones vendor, vendor_boot y odm son particiones principales del proveedor.
Las particiones no actualizables son aquellas cuyo contenido no se actualiza o se actualiza con datos del usuario.
El código de las particiones del sistema y del proveedor puede interactuar a través de una interfaz estable llamada interfaz del proveedor (VINTF).
Particiones del sistema
A continuación, se incluye una lista de todas las particiones del sistema y su uso:
Partición boot. Esta partición contiene una imagen genérica del kernel (GKI).
Esta partición también contiene el disco RAM genérico en los dispositivos lanzados con Android 12 y versiones anteriores. Para obtener más información sobre el ramdisk genérico, consulta Contenido de la imagen de ramdisk genérico.
Partición init_boot (Android 13 y versiones posteriores). Esta partición contiene un ramdisk genérico. En Android 11 y 12, el disco RAM genérico se encuentra en la partición boot.
Partición system. Esta partición contiene la imagen del sistema que se usa para los productos del OEM.
Partición system_ext. Esta partición contiene recursos del sistema y módulos del sistema propietarios que extienden la imagen del sistema común en la partición system.
Partición product. Esta partición puede contener módulos específicos del producto que no se incluyen en ningún otro paquete de particiones.
Partición pvmfw. En esta partición, se almacena el firmware protegido de la máquina virtual (pvmfw), que es el primer código que se ejecuta en las VMs protegidas. Para obtener más información, consulta Firmware de máquina virtual protegida.
Partición generic_bootloader. Esta partición contiene el cargador de arranque genérico.
Particiones de proveedores
A continuación, se incluye una lista de todas las particiones del proveedor y su uso:
Partición vendor_boot. Esta partición contiene código de inicio específico del proveedor. Para obtener más información, consulta Particiones de inicio del proveedor.
Partición recovery. En esta partición, se almacena la imagen de recuperación, que se inicia durante el proceso de actualización inalámbrica (OTA). Los dispositivos que admiten actualizaciones sin interrupciones pueden almacenar las imágenes de recuperación como un ramdisk incluido en la imagen boot o init_boot. Para obtener más información sobre las actualizaciones sin interrupciones, consulta Actualizaciones A/B (sin interrupciones).
Partición misc. Esta partición la usa la partición de recuperación y tiene un tamaño de 4 KB o más.
Partición vbmeta. Esta partición contiene la información del Arranque Verificado para todas las particiones. Esta información verifica que las imágenes instaladas en cada partición sean de confianza. Para obtener más información sobre el inicio verificado, consulta Inicio verificado.
Partición vendor. Esta partición contiene cualquier archivo binario que sea específico del proveedor y no lo suficientemente genérico como para distribuirse al AOSP.
Partición vendor_dlkm. Esta partición contiene módulos del kernel del proveedor. Si almacenas los módulos del kernel del proveedor en esta partición en lugar de la partición vendor, puedes actualizar los módulos del kernel sin actualizar la partición vendor. Para obtener más información, consulta Particiones de DKLM de ODM y del proveedor.
Partición odm. Esta partición contiene las 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 a los ODM reemplazar o personalizar componentes del SoC, y también implementar módulos del kernel para componentes específicos de la placa, daemons y funciones específicas del ODM en capas de abstracción de hardware (HAL). Esta partición es opcional. Por lo general, esta partición 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 está dedicada a almacenar módulos del kernel del ODM. Si almacenas los módulos del kernel del ODM en esta partición, en lugar de en la partición odm, puedes actualizar los módulos del kernel del ODM sin actualizar la partición odm. Para obtener más información, consulta Particiones de DKLM de ODM y del proveedor.
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.
Particiones no actualizables
A continuación, se incluye una lista de todas las particiones que no se pueden actualizar y su uso:
Partición cache. Esta partición contiene datos temporales y es opcional si tu dispositivo usa actualizaciones continuas. Esta partición no necesita ser grabable desde el cargador de arranque, pero sí debe poder borrarse. El tamaño de la partición depende del tipo de dispositivo y de la disponibilidad de espacio en userdata. Por lo general, entre 50 y 100 MB son suficientes.
Partición userdata. Esta partición contiene las apps y los datos instalados por el usuario, incluidos los datos de personalización.
Partición metadata. Si tu dispositivo usa encriptación de metadatos, esta partición contiene la clave de encriptación de metadatos. El tamaño de esta partición es de 16 MB o más, no está encriptada y sus datos no se guardan en instantáneas. Esta partición se borra cuando se restablece la configuración de fábrica del dispositivo.
Reglas y recomendaciones de actualización de particiones
Recomendamos actualizar todas las particiones del sistema en conjunto y todas las particiones del proveedor en otro conjunto. Si actualizas el conjunto de particiones como un todo, puedes realizar pruebas para verificar que las interfaces entre las imágenes de cada partición permanezcan estables.
Independientemente de cómo actualices tus particiones, las siguientes particiones se deben actualizar debido a dependencias estrechamente vinculadas y a la falta de APIs estables:
Las particiones boot y system_dlkm
las particiones init_boot, system, system_ext y product
Particiones dinámicas
Los dispositivos que ejecutan Android 11 y versiones posteriores pueden admitir particiones dinámicas, que son un sistema de partición de espacio de usuario para Android que te 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.
Variantes de productos de Soong
El sistema de compilación 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 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 del producto, se debe definir product_available: true. Algunas bibliotecas del VNDK sin product_available: true no están disponibles para los módulos del producto.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-27 (UTC)"],[],[],null,["# Partitions overview\n\nAndroid devices contain several *partitions* or specific sections of storage\nspace used to contain specific parts of the device's software. Each partition\ncontains a *partition image* (an IMG file) or snapshot of all the software for\nthe partition. Figure 1 shows the layout of core partitions on a device:\n\n**Figure 1.** Layout of core partitions.\n\nPartitions are classified in three categories:\n\n- *System partitions* are partitions that are updated when updating the OS\n and other features. The `system`, `boot`, and `init_boot` are core system\n partitions.\n\n- *Vendor partitions* contain device and hardware-specific code that might\n never be updated after initial release. The `vendor`, `vendor_boot`, and `odm`\n partitions are core vendor partitions.\n\n- *Nonupdatable partitions* are partitions whose contents are either not updated\n or updated with user data.\n\nCode in system and vendor partitions can interact using a stable interface\ncalled the *vendor interface (VINTF)*.\n| **Note:** The separation of system partitions from vendor partitions was part of an Android 11 effort called *Project Treble*. With this architecture, you can update a device's operating system and apps without updating any of hardware-specific code.\n\n### System partitions\n\nFollowing is a list of all system partitions and their use:\n\n- **`boot` partition.** This partition contains a Generic Kernel Image (GKI).\n This partition also contains the generic ramdisk in devices launched in\n Android 12 and lower. For further information on generic ramdisk, see\n [Generic ramdisk image contents](/docs/core/architecture/partitions/generic-boot#generic-boot-ramdisk-image-contents).\n\n- **`init_boot` partition (Android 13 and higher).** This partition contains a\n generic ramdisk. In Android 11 and 12, the generic ramdisk is in the\n `boot` partition.\n\n- **`system` partition.** This partition contains the system image used\n for OEM products.\n\n- **`system_ext` partition.** This partition contains system resources and\n proprietary system modules that extend the common system image in the `system`\n partition.\n\n | **Note:** *Single system image (SSI)* refers to a file, such as a zip file that contains the images of the `system` and `system_ext` partitions and reuses those images across a set of target devices. For further information on SSI, see [Android shared system image](/docs/core/architecture/partitions/shared-system-image).\n- **`system_dlkm` partition.** This partition contains GKI modules. For further\n information on this partition, see [Implement a GKI module partition](/docs/core/architecture/partitions/gki-partitions).\n\n- **`product` partition.** This partition can contain product-specific modules\n that aren't bundled with any other partitions.\n\n | **Note:** The [*Vendor Native Development Kit (VNDK)*](/docs/core/architecture/vndk) is a set of libraries installed in the `system` partition and designed exclusively for vendors to implement their HALs. The `product` and `vendor` partitions can link to VNDK libraries in the `system` partition, but can't link to other libraries in the `system` partition.\n- **`pvmfw` partition.** This partition stores the Protected Virtual Machine\n Firmware (pvmfw) which is the first code that runs in protected VMs. For more\n information, see [Protected Virtual Machine Firmware](https://android.googlesource.com/platform/packages/modules/Virtualization/+/refs/heads/android16-release/guest/pvmfw/README.md).\n\n- **`generic_bootloader` partition.** This partition contains the generic bootloader.\n\n### Vendor partitions\n\nFollowing is a list of all vendor partitions and their use:\n\n- **`vendor_boot` partition.** This partition contains vendor-specific boot\n code. For more information, see [Vendor boot partitions](/docs/core/architecture/partitions/vendor-boot-partitions).\n\n- **`recovery` partition.** This partition stores the recovery image, which is\n booted during the over-the-air (OTA) update process. Devices that support\n seamless updates can store the recovery images as a ramdisk contained in the\n `boot` or `init_boot` image. For more information on seamless updates,\n see [A/B (seamless) updates](/docs/core/ota/ab).\n\n- **`misc` partition.** This partition is used by the recovery partition and is\n 4 KB or larger.\n\n- **`vbmeta` partition.** This partition contains the Verified Boot information\n for all of the partitions. This information verifies that the images installed\n in each partition is trusted. For further information on\n Verified Boot, see\n [Verified Boot](/docs/security/features/verifiedboot).\n\n- **`vendor` partition.** This partition contains any binary that is vendor\n specific and not generic enough to distribute to AOSP.\n\n | **Note:** The [*Vendor Native Development Kit (VNDK)*](/docs/core/architecture/vndk) is a set of libraries installed in the `system` partition and designed exclusively for vendors to implement their HALs. The `product` and `vendor` partitions can link to VNDK libraries in the `system` partition, but can't link to other libraries in the `system` partition.\n- **`vendor_dlkm` partition.** This partition contains vendor\n kernel modules. By storing vendor kernel modules in this partition\n instead of the `vendor` partition, you can update kernel\n modules without updating the `vendor` partition. For more information, see\n [Vendor and ODM DKLM partitions](/docs/core/architecture/partitions/vendor-odm-dlkm-partition).\n\n- **`odm` partition.** This partition contains original design manufacturer\n (ODM)\n customizations to system-on-chip (SoC) vendor board-support packages (BSPs).\n Such customizations enable ODMs to replace or customize SoC components, and\n implement kernel modules for board-specific components, daemons, and\n ODM-specific features on hardware abstraction layers (HALs). This partition is\n optional. Typically this partition is used to contain customizations so that\n devices can\n use a single vendor image for multiple hardware SKUs. For more information,\n see [ODM partitions](/docs/core/architecture/bootloader/partitions/odm-partitions).\n\n- **`odm_dlkm` partition.** This partition is dedicated to storing ODM kernel\n modules. By storing ODM kernel modules in the this partition, instead of\n the `odm` partition, you can update ODM kernel modules without updating the\n `odm` partition. For more information, see\n [Vendor and ODM DKLM partitions](/docs/core/architecture/partitions/vendor-odm-dlkm-partition).\n\n- **`radio` partition.** This partition contains the radio image and is needed\n only for devices that include a radio with radio-specific software in a\n dedicated partition.\n\n| **Note:** Devices that support seamless updates need two partitions, referred to as *slots* (slot A and slot B) for the `boot`, `system`, `vendor`, and `radio` partitions. For further information, see [Partition selection (slots)](/docs/core/ota/ab#slots).\n\n### Nonupdatable partitions\n\nFollowing is a list of all nonupdatable partitions and their use:\n\n- **`cache` partition.** This partition contains temporary data and is optional\n if your device uses seamless updates. This partition doesn't need to be\n writable from the bootloader, but needs to be erasable. The partition\n size depends on the device type and the availability of space on `userdata`;\n typically, 50 to 100 MB is sufficient.\n\n- **`userdata` partition.** This partition contains user-installed apps and\n data, including customization data.\n\n- **`metadata` partition.** If your device uses [metadata encryption](/docs/security/features/encryption/metadata),\n this partition contains the metadata encryption key. The size of this\n partition is 16 MB or larger, it isn't encrypted, and its data isn't\n snapshotted. This partition is erased when the device is factory reset.\n\nPartition update rules and recommendations\n------------------------------------------\n\nWe recommend updating all system partitions as a whole\nand all vendor partitions as another whole. By updating the set of partitions as\na whole, you can test to verify the interfaces between images in each partition\nremain stable.\n\nRegardless of how you update your partitions, the following partitions must\nbe updated due to tightly coupled dependencies and lack of stable APIs:\n\n- The `boot` and `system_dlkm` partitions\n- the `init_boot`, `system`, `system_ext`, and `product` partitions\n\n| **Note:** If all interfaces between the `product` partition and other system partitions have stable ABIs, you can update the `product` partition independently. For furthe information, see [Maintain ABIs between partitions](/docs/core/architecture/partitions/product-partitions#maintaining-abis).\n\nDynamic partitions\n------------------\n\nDevices running Android 11 and higher can support\ndynamic partitions, which are a userspace partitioning system for Android that\nlets you create, resize, or destroy partitions during over-the-air (OTA)\nupdates. For more information, see [Dynamic partitions](/docs/core/ota/dynamic_partitions).\n\n### Soong product variants\n\nThe [Soong](/docs/setup/build) build system uses image variants to split\nbuild dependencies. Native modules (`/build/soong/cc`) can mutate system\nprocess modules to the core variant and vendor process modules to the\nvendor variant; a module in one image variant can't link to other modules in\na different image variant.\n\nIn Android 12 or higher, a system module with\n`vendor_available: true` creates a vendor variant in addition to the core\nvariant. To create a product variant, `product_available: true` must be\ndefined. Some VNDK libraries without `product_available: true` aren't\navailable to product modules."]]
