Flashing instructions written before 2019 assume every partition is a fixed physical slice of storage that Fastboot can address by name directly. Starting with Android 10, Google introduced dynamic partitions, which restructured how system, vendor, product, and related partitions are stored, and it broke enough old flashing habits that it is worth understanding rather than just copying commands from an outdated forum thread.
Before dynamic partitions, system, vendor, and product were each their own fixed physical partition with a size set at the factory. Resizing one required repartitioning the whole device, which OEMs avoided doing after launch. Dynamic partitions solve this by wrapping those partitions inside a single container partition called super, where each logical partition can grow or shrink as needed within the container's total size, similar to how LVM volumes work inside a single disk on Linux.
The partitions inside super are called logical partitions. They still have the same names you are used to — system, vendor, product, system_ext on some devices — but they no longer exist as independently addressable physical partitions from the bootloader's point of view.
Bootloader-level Fastboot (the mode you reach with adb reboot bootloader) can only see physical partitions. It has no concept of the logical partitions living inside super. To flash system.img or vendor.img on a dynamic-partition device, you need fastbootd, the userspace Fastboot implementation that boots as a limited Android environment and does understand the logical partition layout:
fastboot reboot fastbootRunning this from bootloader Fastboot transitions into fastbootd. From there, the same flash commands work as before, but now they correctly resolve against the logical partition table:
fastboot flash system system.img
fastboot flash vendor vendor.imgTrying to run those same commands from plain bootloader Fastboot on an affected device returns an error along the lines of "partition table doesn't exist" or "unknown partition," which is the most common symptom of using the wrong Fastboot mode rather than an actual problem with the image file.
Full factory images for dynamic-partition devices often include a single super.img file instead of separate system.img and vendor.img files. This can only be flashed from fastbootd as well:
fastboot flash super super.imgThis single command replaces the entire logical partition container in one step, which is why official factory image flashing scripts for recent devices have largely moved to shipping one super.img rather than several separate images — it is simpler to generate and simpler to flash atomically.
Most devices with dynamic partitions also use A/B seamless updates, meaning there are two copies of each logical partition (slot A and slot B) so an update can install to the inactive slot while the device keeps running on the active one. Flashing a logical partition normally targets the currently active slot automatically. If you need to target a specific slot explicitly, append --slot=a or --slot=b to the command, or use fastboot --set-active=other beforehand to switch which slot is active before flashing.
Custom ROM installers sometimes need to resize a logical partition — enlarging product to fit a GApps package, for example. This is done with fastboot delete-logical-partition and fastboot create-logical-partition commands, or more commonly left to the ROM's own installer script, since manual resizing without understanding the container's total available space can leave the super partition in an inconsistent state that prevents any further flashing until it is recreated from scratch via a full factory image restore.
From fastbootd or bootloader mode, run:
fastboot getvar is-userspace
fastboot getvar super-partition-nameA device without dynamic partitions returns nothing meaningful for the second command, and fastboot flash system system.img works directly from bootloader Fastboot without needing the fastbootd transition at all.
On a dynamic-partition device, the standard wipe flag fastboot -w (used alongside a flash-all script to clear userdata) still only targets the userdata partition, not the logical partitions inside super. It is easy to assume a full flash-all with -w resets everything back to a clean factory state including system and vendor, but those are replaced only because the flash-all script explicitly flashes a fresh super.img as a separate step, not because -w itself touches them. If you write a custom flashing script and skip the super.img flash step by mistake, -w alone will not catch that omission or produce any warning about it.