The Problem with the Monolithic Android Mess
How long did it take to get a software update on an early Android phone? Often, the answer was 18 months of waiting. That delay was the direct result of a structural nightmare inside the operating system. In the early days, Android dumped all code into a single giant /system partition. Google's generic framework code sat right next to Qualcomm's proprietary camera drivers and Samsung's custom launcher apps.
Because everything shared the same space, you could not update one piece without breaking the others. Upgrading an Android 7 phone to Android 8 meant the manufacturer had to wait for the silicon vendor to rewrite their proprietary drivers to match the new framework. This rigid dependency chain required a full firmware rewrite for every major release.
Warning: Do not confuse the modern
/systempartition with older AOSP documentation. Early documentation might still refer to/systemas a monolithic entity containing all hardware drivers.
To fix this massive bottleneck, Google had to completely change how it packaged the operating system. That change was Project Treble, a massive architectural redesign that physically separated these dependencies into distinct partitions.
Project Treble: Splitting the Framework from the Silicon
How do you update an operating system without touching the hardware drivers? You move them into a completely different room and lock the door. Silicon code and generic OS code could not safely exist in the same space without breaking each other. Project Treble solved this by splitting the OS into two distinct spaces. The Android system vendor partitions separate the generic framework from the specific hardware, with the /system partition holding pure Google code. Meanwhile, the /vendor partition strictly isolates the proprietary hardware drivers provided by the silicon manufacturer.
To enforce this separation, Android established a strict boundary. The /system partition cannot directly load shared libraries from the /vendor partition.
Interview Note: Being able to explain that
systemandvendormust communicate via IPC like Binder or AIDL is a common AOSP interview question. Always emphasize that this boundary prevents direct library linking.
The following diagram shows the Treble architecture separating the generic framework from the vendor implementation. This visualizes the strict IPC boundary that prevents direct access between the two domains.
Inside the diagram, native core services talk to the hardware abstraction layers across the boundary via Binder or AIDL. The core framework never touches the proprietary drivers directly.
This strict isolation enables a powerful capability called the Generic System Image (GSI). A developer can completely wipe the /system partition and replace it with a pure Google GSI. The phone will still boot and operate the camera perfectly because the /vendor partition remains untouched. While Treble fixed the silicon problem, device makers still needed a place to put their own themes without dirtying the clean system partition.
Where the Bloatware and Motherboards Live: product and odm
If the system partition is purely Google and the vendor partition is strictly Qualcomm, where does a custom manufacturer launcher go? Original Equipment Manufacturers (OEMs) and Original Design Manufacturers (ODMs) need to customize devices heavily. However, they must do this without breaking the strict GSI compliance that Project Treble established. To solve this, Google introduced the AOSP product and odm partitions. These highly specialized partitions keep OEM bloatware out of the system image and board-specific hacks out of the vendor image.
Think of a car. The system partition is the generic engine control software, and the vendor partition is the engine manufacturer's specific driver. Your product partition is the dealer's custom radio and paint job. Finally, the odm partition is the specific physical wiring harness for that exact trim level.
A single OEM might design one phone model but source the physical motherboard from three different ODMs depending on the regional market. The system, vendor, and product partitions remain identical across all regions. Each region gets a different odm partition to handle the varied physical board layouts.
Common Mistake: Beginners often confuse OEM and ODM. An OEM brands the device, while an ODM physically builds the printed circuit board.
Now that we know what these four partitions contain and why they exist, how does the device actually find and load them into the filesystem during the Android boot sequence?
How init Mounts the OS: The fstab File
Where do these files actually live on the physical flash memory chip? The Linux kernel has started, but the OS partitions remain raw physical block devices. Your system needs a map to know which physical block device corresponds to which logical folder. The init process solves this by reading the fstab (File System Table) located in the vendor ramdisk. This table dictates exactly how the physical storage maps to the logical filesystem.
Here is an example snippet of a standard Android fstab file showing the partition mapping.
# <src> <mnt_point> <type> <mnt_flags and options>
/dev/block/bootdevice/by-name/vendor /vendor erofs ro,barrier=1
The init process reads that line and grabs the physical block device. Next, the initialization daemon sets up an EROFS filesystem in memory and maps that filesystem to the /vendor folder. Notice the ro flag in the options column.
Common Mistake: Android mounts these OS partitions as read-only (
ro). Modifying their contents requires explicitly remounting them or using dynamic partition overlays.
By reading the fstab, the init process successfully attaches the separate blocks of storage into one cohesive directory structure. The OS actively enforces strict boundaries separating the generic code, the silicon drivers, the manufacturer apps, and the motherboard configs. These OS files now sit fully mounted and accessible. However, they remain dormant files resting on a disk. How does the init process wake them up to start the giant, living Android framework?