System Partitions Overview

Unlike a traditional desktop operating system where everything is typically installed on a single C:\ drive or root / partition, Android's internal storage (eMMC or UFS) is strictly divided into multiple logical blocks known as partitions.

This strict isolation is vital for system security, factory resets, Over-The-Air (OTA) updates, and the separation of generic Google code from hardware-specific vendor code.

Note: We will perform a deep dive into partitions in Module 5. This lesson provides the foundational overview.

The Core Partitions

While a modern Android device can have over 50 individual partitions, these are the most critical ones you must understand:

1. boot

The boot partition is the very first piece of the Android OS to load into memory.

• Contents: It contains the Linux Kernel binary (Image or zImage) and the initial RAM disk (ramdisk).
• Role: It initializes the device hardware, mounts the other necessary partitions, and starts the init process, effectively booting the operating system.

2. system

The system partition contains the core Android OS framework.

• Contents: The Java API framework (framework.jar), pre-installed system apps (SystemUI.apk), default fonts, and core native binaries (like SurfaceFlinger).
• Role: This partition is built directly from the AOSP source code. It is mounted as read-only to ensure malicious apps cannot permanently modify or infect the core operating system.

3. vendor

Introduced primarily with Project Treble (Android 8.0), the vendor partition contains all hardware-specific code.

• Contents: Hardware Abstraction Layers (HALs), proprietary blobs, and SoC-specific binaries provided by manufacturers like Qualcomm, MediaTek, or Samsung.
• Role: By separating hardware drivers from the /system partition, OEMs can safely update the generic Android OS framework without needing silicon vendors to rewrite their proprietary hardware drivers.

4. userdata (or data)

This is the only primary partition that the user interacts with.

• Contents: Third-party apps downloaded from the Play Store, app data, photos, videos, and settings.
• Role: Unlike system and vendor, userdata is mounted as read-write.
• Factory Reset: When you perform a "Factory Data Reset" on a phone, the system simply wipes the /data partition clean. Because the /system partition is read-only, the phone boots back to its pristine factory state.

You can inspect the currently mounted partitions and their file systems via the ADB shell:

adb shell df -h

Secondary Framework Partitions

As Android evolved, Google recognized the need to further isolate different types of system software. You will frequently encounter these modern partitions:

• product: Contains customizations specific to a particular device model or OEM (like custom wallpapers, OEM-specific system apps, or customized system properties). It separates OEM bloatware from the pure AOSP /system partition.
• system_ext: Contains system modules and apps that rely on hidden Android APIs but are not strictly part of the core AOSP framework.
• odm (Original Design Manufacturer): Similar to the /vendor partition, but specifically for board-level customizations by the hardware manufacturer.

# Finding out exactly which block device points to the vendor partition
adb shell ls -l /dev/block/bootdevice/by-name/ | grep vendor

Partition Layout and OTA Updates

The partition layout drastically impacts how an Android device updates.

Modern Android devices utilize an A/B Partition scheme. Instead of one /system partition, the device has two: system_a and system_b (and similarly for boot and vendor).

When your phone downloads an OTA update, it writes the new OS entirely to the inactive "B" partitions in the background while you continue using the active "A" partitions. Upon reboot, the bootloader simply swaps the active slot, resulting in an update that takes seconds rather than minutes, and providing a seamless fallback if the update fails.