Android devices include several partitions that serve different functions in the boot process.

Standard partitions

  • boot. This partition contains a kernel image and a ramdisk image combined using mkbootimg. You can use a virtual partition to flash either image directly without flashing a new boot partition.

    • 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.

  • system. This partition contains the Android framework.

  • odm. 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.

  • recovery. 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 image (rather than a separate image).

  • cache. 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 parition size depends on the device type and the availability of space on userdata; typically, 50 MB–100 MB is sufficient.

  • misc. This partition is used by the recovery partition and is 4 KB or larger.

  • userdata. This partition contains user-installed apps and data, including customization data.

  • metadata. This partition is used when device is encrypted. The size is 16 MB or larger.

  • vendor. This partition contains any binary that isn't distributable to AOSP. If the device doesn't contain proprietary information, you can omit this partition.

  • radio. 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. This partition stores the binary image of the Trusty OS and is used only if the device includes Trusty. For details, see TOS Partitions.

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.

Designating critical partitions

If the device requires specific partitions or data to run, you must designate those partitions/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 and 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 and higher, a system module can also create a product variant (in addition to core and vendor variants) by defining vendor_available: true.