Overview

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 using mkbootimg. 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 the vendor, system, or dtb 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 the odm_dlkm partition (as opposed to the odm partition) makes it possible to update ODM kernel modules without updating the odm 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 the boot or init_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 on userdata; 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 the vendor_dlkm partition (as opposed to the vendor partition) makes it possible to update kernel modules without updating the vendor 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.

Android Partition Layout

Figure 1. Partition layout in Android 11

  • Single System Image (SSI). A new, conceptual image that contains the system and system_ext images. When these partitions are common for a set of target devices, those devices can share the SSI and skip building the system and system_ext images.

  • system_ext partition. A new partition that can use system 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 the system partition later.

    • Bundle OEM or SoC-specific modules. We recommend unbundling such modules so they can be installed to the product or vendor partition.

  • system partition. Common system image used for OEM products. We recommend moving proprietary modules out of the system partition, either by upstreaming them to AOSP or by moving them to the system_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 the system partition, but can't link to other libraries in the system partition. Native modules in the product partition can link to any library in the system partition.

  • In Android 11 and higher, 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.

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 its Android.bp files; this enables vendor modules to link to system modules. VNDK libraries, which are vendor variants of system libraries, can also create vendor variants for vendor modules by defining vendor_available: true in its Android.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 without product_available: true aren't available to product modules.