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
, andinit_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
, andodm
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 theboot
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 thesystem
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 theboot
orinit_boot
image. For more information on seamless updates, see A/B (seamless) updates.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 thevendor
partition, you can update kernel modules without updating thevendor
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 theodm
partition, you can update ODM kernel modules without updating theodm
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 onuserdata
; 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
andsystem_dlkm
partitions - the
init_boot
,system
,system_ext
, andproduct
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.
misc
partition. This partition is used by the recovery partition and is 4 KB or larger.tos
partition. This partition contains the binary image of the Trusty OS and is used only if the device includes Trusty. For more information, see Trusty OS (TOS) 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.