Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
Android devices contain several partitions or specific sections of storage
space used to contain specific parts of the device's software. Each partition
contains a partition image (an IMG file) or snapshot of all the software for
the partition. Figure 1 shows the layout of core partitions on a device:
Figure 1. Layout of core partitions.
Partitions are classified in three categories:
System partitions are partitions that are updated when updating the OS
and other features. The system, boot, and init_boot are core system
partitions.
Vendor partitions contain device and hardware-specific code that might
never be updated after initial release. The vendor, vendor_boot, and odm
partitions are core vendor partitions.
Nonupdatable partitions are partitions whose contents are either not updated
or updated with user data.
Code in system and vendor partitions can interact using a stable interface
called the vendor interface (VINTF).
System partitions
Following is a list of all system partitions and their use:
boot partition. This partition contains a Generic Kernel Image (GKI).
This partition also contains the generic ramdisk in devices launched in
Android 12 and lower. For further information on generic ramdisk, see
Generic ramdisk image contents.
init_boot partition (Android 13 and higher). This partition contains a
generic ramdisk. In Android 11 and 12, the generic ramdisk is in the
boot partition.
system partition. This partition contains the system image used
for OEM products.
system_ext partition. This partition contains system resources and
proprietary system modules that extend the common system image in the system
partition.
system_dlkm partition. This partition contains GKI modules. For further
information on this partition, see Implement a GKI module partition.
product partition. This partition can contain product-specific modules
that aren't bundled with any other partitions.
pvmfw partition. This partition stores the Protected Virtual Machine
Firmware (pvmfw) which is the first code that runs in protected VMs. For more
information, see Protected Virtual Machine Firmware.
generic_bootloader partition. This partition contains the generic bootloader.
Vendor partitions
Following is a list of all vendor partitions and their use:
vendor_boot partition. This partition contains vendor-specific boot
code. For more information, see Vendor boot partitions.
recovery partition. This partition stores the recovery image, which is
booted during the over-the-air (OTA) update process. Devices that support
seamless updates can store the recovery images as a ramdisk contained in the
boot or init_boot image. For more information on seamless updates,
see A/B (seamless) updates.
misc partition. This partition is used by the recovery partition and is
4 KB or larger.
vbmeta partition. This partition contains the Verified Boot information
for all of the partitions. This information verifies that the images installed
in each partition is trusted. For further information on
Verified Boot, see
Verified Boot.
vendor partition. This partition contains any binary that is vendor
specific and not generic enough to distribute to AOSP.
vendor_dlkm partition. This partition contains vendor
kernel modules. By storing vendor kernel modules in this partition
instead of the vendor partition, you can update kernel
modules without updating the vendor partition. For more information, see
Vendor and ODM DKLM partitions.
odm partition. This partition contains original design manufacturer
(ODM)
customizations to system-on-chip (SoC) vendor board-support packages (BSPs).
Such customizations enable ODMs to replace or customize SoC components, and
implement kernel modules for board-specific components, daemons, and
ODM-specific features on hardware abstraction layers (HALs). This partition is
optional. Typically this partition is used to contain customizations so that
devices can
use a single vendor image for multiple hardware SKUs. For more information,
see ODM partitions.
odm_dlkm partition. This partition is dedicated to storing ODM kernel
modules. By storing ODM kernel modules in the this partition, instead of
the odm partition, you can update ODM kernel modules without updating the
odm partition. For more information, see
Vendor and ODM DKLM partitions.
radio partition. This partition contains the radio image and is needed
only for devices that include a radio with radio-specific software in a
dedicated partition.
Nonupdatable partitions
Following is a list of all nonupdatable partitions and their use:
cache partition. This partition contains temporary data and is optional
if your device uses seamless updates. This partition doesn't need to be
writable from the bootloader, but needs to be erasable. The partition
size depends on the device type and the availability of space on userdata;
typically, 50 to 100 MB is sufficient.
userdata partition. This partition contains user-installed apps and
data, including customization data.
metadata partition. If your device uses metadata encryption,
this partition contains the metadata encryption key. The size of this
partition is 16 MB or larger, it isn't encrypted, and its data isn't
snapshotted. This partition is erased when the device is factory reset.
Partition update rules and recommendations
We recommend updating all system partitions as a whole
and all vendor partitions as another whole. By updating the set of partitions as
a whole, you can test to verify the interfaces between images in each partition
remain stable.
Regardless of how you update your partitions, the following partitions must
be updated due to tightly coupled dependencies and lack of stable APIs:
The boot and system_dlkm partitions
the init_boot, system, system_ext, and product partitions
Dynamic partitions
Devices running Android 11 and higher can support
dynamic partitions, which are a userspace partitioning system for Android that
lets you create, resize, or destroy partitions during over-the-air (OTA)
updates. For more information, see Dynamic partitions.
Soong product variants
The Soong build system uses image variants to split
build dependencies. Native modules (/build/soong/cc) can mutate system
process modules to the core variant and vendor process modules to the
vendor variant; a module in one image variant can't link to other modules in
a different image variant.
In Android 12 or higher, a system module with
vendor_available: true creates a vendor variant in addition to the core
variant. To create a product variant, product_available: true must be
defined. Some VNDK libraries without product_available: true aren't
available to product modules.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-07-15 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-07-15 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."]]