On Android, internal storage is divided into partitions, that is, logical blocks that contain software images (I'M G) with very specific functions. It's not all about "space for your photos": : a significant part is reserved for booting the system and making the hardware work as it should.
The modern Android architecture (as of Treble) separates the generic system code of the manufacturer-dependent code into three large groups: system partitions (e.g., system, boot, init_boot), provider partitions (such as vendor, vendor_boot, odm) and non-updatable partitions (userdata, cache, metadata). This separation is coordinated through a stable interface called VINTF which allows you to update the system without touching the hardware-specific code.
What exactly are boot, system and vendor for?
The three protagonists of this guide are the heart of the system: define how Android boots, where the framework lives y where the hardware binaries are hosted. Understanding its functions prevents errors when flashing and gives you criteria when updating.
Boot partition
Partition boot contains the boot image with the kernel. In Android 11 the GKI (Generic Kernel Image), which standardizes the kernel and displaces vendor_boot Vendor-specific information and RAM disk. In Android 12, you can still find the generic RAM disk. boot, but since Android 13 that generic ramdisk moves to init_bootThis evolution makes the kernel more generic and encapsulates hardware-dependent code where necessary.
Important for flashing: if you delete boot without flashing a valid image, the device will not boot. And if you use GKI, remember that boot and system_dlkm must be updated together due to its narrow quarters.
System partition
system houses the operating system itself: Android framework, system apps, and common libraries. Since Android 10-11, it is complemented by system_ext (proprietary resources and modules that extend the common image) and with product (product-specific modules). There is a set of linking rules: VNDK (Vendor Native Development Kit), installed on system, to which they can link product y vendor without touching other libraries system. This separation maintains ABI stable and allows, in some cases, to update product separately if all interfaces are stable.
Beware of the "wipe system": delete system removes the operating system. The phone can boot into the bootloader or recovery, but won't boot Android until you flash a valid ROM.
Vendor partition
vendor contains binaries, HALs and hardware-specific libraries that are not generic enough for AOSP: SoC drivers, daemons, vendor kernel modules (if not outsourced to vendor_dlkm) and board-related customizations. With Treble, System and vendor exchange only through VINTF, which reduces compatibility breakage in system updates.
Key extensions: vendor_dlkm allow update vendor kernel modules without touching the partition vendor. For its part, odm y odm_dlkm Store original design manufacturer (ODM) customizations to support multiple SKUs with a single image. vendor.
Other relevant partitions you'll see on Android
In addition to the protagonists, there are a good handful of partitions that complete the puzzle.Knowing them will clarify messages from recovery, OTA, and flashing tools.
- Of the system:
init_boot(generic ramdisk since Android 13),system_ext(extendssystem),system_dlkm(GKI modules),product(product modules),pvmfw(protected virtual machine firmware),generic_bootloader(generic charger). - From the supplier:
vendor_boot(vendor boot code and vendor ramdisks),recovery(recovery image, which in A/B can go as ramdisk inboot/init_boot),misc(used by recovery, it is usually very small),vbmeta(Verified Boot metadata),vendor,vendor_dlkm,odm,odm_dlkm,radio(radio firmware if applicable). - Not upgradeable:
cache(temporary; in A/B it is sometimes dispensable),userdata(apps and user data),metadata(metadata encryption key if used; erased on factory reset).
Devices with seamless updates (A/B): They maintain two slots (A and B) for boot, system, vendor y radio, facilitating seamless OTA. Images are applied to the inactive slot and toggled on reboot.
Update rules and dependencies between partitions
Updating with consistent sets avoids compatibility breaksIt is recommended to update all system partitions in bulk and all vendor partitions separately, ensuring that the interfaces between images remain stable.
Unavoidable dependencies: always updates together boot y system_dlkm, and init_boot, system, system_ext y product. If all interfaces between product and the rest of the system do Stable ABI, product can be updated independently.
Verified Boot and vbmeta: the partition vbmeta includes verified boot information that ensures the integrity of all signed partitionsIf something doesn't fit, the device may refuse to load that image.
Dynamic Partitions: More Flexibility in OTA
Since Android 11, many devices support dynamic partitions., a user-space partitioning system that allows partitions to be created, resized, or destroyed during an OTA without reflashing the entire table. This makes updates faster and improves space utilization.
Practical advantage: : the manufacturer can adjust sizes of system/product/vendor as the software evolves, without destructive changes to the partitioning scheme.
