Android devices include several partitions that serve different functions in the boot process.
Standard partitions
boot
partition. This partition contains a kernel image and is created usingmkbootimg
. You can use a virtual partition to flash either image directly without flashing a new boot partition. This partition also contains the generic ramdisk in devices launched before Android 13.kernel. The virtual
kernel
partition overwrites the kernel (zImage
,zImage-dtb
,Image.gz-dtb
) by writing the new kernel image over the old kernel image. If the development kernel supplied is incompatible, you might need to update thevendor
,system
, ordtb
partition (if present) with associated kernel modules.ramdisk. The virtual
ramdisk
partition overwrites the ramdisk by writing the new ramdisk image over the old ramdisk image.
The overwrite operation determines the start location of the existing image in eMMC and copies the new image to that location. The new image (kernel or ramdisk) might be larger than the existing one; to make space, the bootloader can move data following the image or abandon the operation with an error.
init_boot
partition. This partition contains the generic ramdisk for devices launching with Android 13 and beyond.system
partition. This partition contains the Android framework.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, it's used to contain customizations so that devices can use a single vendor image for multiple hardware SKUs. For details, see ODM Partitions.odm_dlkm
partition. This partition is dedicated to storing ODM kernel modules. Storing ODM kernel modules in theodm_dlkm
partition (as opposed to theodm
partition) makes it possible to update ODM kernel modules without updating theodm
partition.recovery
partition. This partition stores the recovery image, which is booted during the OTA process. Devices that support seamless updates can store the recovery images as a ramdisk contained in theboot
orinit_boot
image (rather than a separate image).cache
partition. This partition stores temporary data and is optional if a device uses seamless updates. The cache partition doesn't need to be writable from the bootloader, but does need to be erasable. The partition size depends on the device type and the availability of space onuserdata
; typically, 50 MB–100 MB is sufficient.misc
partition. This partition is used by the recovery partition and is 4 KB or larger.userdata
partition. This partition contains user-installed apps and data, including customization data.metadata
partition. This partition is used to store the metadata encryption key when the device uses metadata encryption. The size is 16 MB or larger. It isn't encrypted and its data isn't snapshotted. It is erased when the device is factory reset. Usage of this partition is strictly limited.vendor
partition. This partition contains any binary that isn't distributable to AOSP. If the device doesn't contain proprietary information, you can omit this partition.vendor_dlkm
partition. This partition is dedicated to storing vendor kernel modules. Storing vendor kernel modules in thevendor_dlkm
partition (as opposed to thevendor
partition) makes it possible to update kernel modules without updating thevendor
partition.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.tos
partition. This partition stores the binary image of the Trusty OS and is used only if the device includes Trusty. For details, see TOS Partitions.pvmfw
partition. This partition stores the Protected Virtual Machine Firmware (pvmfw) which is the first code that runs in protected VMs. See Protected Virtual Machine Firmware for more detail.
Dynamic partitions
Devices running Android 11 and higher can support dynamic partitions, which are a userspace partitioning system for Android that enables creating, resizing, or destroying partitions during over-the-air (OTA) updates. For details, see Dynamic partitions.
Designate critical partitions
If the device requires specific partitions or data to run, you must designate
those partitions or data as either fully protected or as re-flashable, meaning
they are re-buildable, provided, or extractable using a fastboot oem
command.
This includes data such as per-device factory-specific settings, serial numbers,
calibration data, and more.
Changes in Android 11
Android 11 includes numerous changes to partitions, including restrictions on linking to libraries and new Soong image variants.
Figure 1. Partition layout in Android 11
Single System Image (SSI). A new, conceptual image that contains the
system
andsystem_ext
images. When these partitions are common for a set of target devices, those devices can share the SSI and skip building thesystem
andsystem_ext
images.system_ext
partition. A new partition that can usesystem
resources and can include system modules that:Extend AOSP system modules in the
system
partition. We recommend upstreaming such modules to AOSP so they can be installed to thesystem
partition later.Bundle OEM or SoC-specific modules. We recommend unbundling such modules so they can be installed to the
product
orvendor
partition.
system
partition. Common system image used for OEM products. We recommend moving proprietary modules out of thesystem
partition, either by upstreaming them to AOSP or by moving them to thesystem_ext
partition.product
partition. This partition can now use permitted interfaces to install product-specific modules that aren't bundled with any other partitions.
VNDK changes
The Vendor Native Development Kit (VNDK)
is a set of libraries installed in the system
partition and designed
exclusively for vendors to implement their HALs.
In Android 10 and lower, the
vendor
partition can link to VNDK libraries in thesystem
partition, but can't link to other libraries in thesystem
partition. Native modules in theproduct
partition can link to any library in thesystem
partition.In Android 11 and higher, the
product
andvendor
partitions can link to VNDK libraries in thesystem
partition, but can't link to other libraries in thesystem
partition.
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 10 or lower, a system module automatically creates core variants. It can also create vendor variants by defining
vendor_available: true
in itsAndroid.bp
files; this enables vendor modules to link to system modules. VNDK libraries, which are vendor variants ofsystem
libraries, can also create vendor variants for vendor modules by definingvendor_available: true
in itsAndroid.bp
files (see example).In Android 11, a system module can also create a product variant (in addition to core and vendor variants) by defining
vendor_available: true
.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 withoutproduct_available: true
aren't available to product modules.