Introduction to System-as-Root (SAR)

Android’s System-as-Root (SAR) is a significant architectural change introduced with Android 10, fundamentally altering how the operating system’s core components are structured on device storage. Before SAR, the root filesystem (containing `/init` and other critical boot files) was separate from the `/system` partition, residing within the `boot.img` as a ramdisk. SAR unifies these, making the `/system` partition itself the root filesystem. This change was driven primarily by the adoption of Generic System Images (GSI) and the desire to simplify A/B update mechanisms, offering a more streamlined and robust system for Android devices.

The Evolution of Android Partitioning

Pre-SAR: Separate System and Ramdisk

In older Android versions (pre-Android 10), the device’s storage was typically divided into several partitions, including `/system`, `/vendor`, `/data`, and `/boot`. The `boot` partition contained the kernel and a ramdisk. This ramdisk was a small, self-contained filesystem that would be loaded into RAM at boot, providing the initial `/` (root directory) and executing `/init`. After `init` performed its initial tasks, it would then mount the larger `/system` partition onto `/system`, effectively overlaying its contents. The `/` itself remained the ramdisk’s root.

For instance, an old `boot.img` might look like this:

boot.img
├── kernel
└── ramdisk.img
    ├── init
    ├── init.rc
    └── lib

This separation meant that modifying the root filesystem required patching the `ramdisk.img` within the `boot.img`, distinct from any changes made to the `/system` partition.

The Shift to System-as-Root

With System-as-Root, the ramdisk no longer serves as the primary root filesystem. Instead, the `/system` partition is directly mounted as `/`. The critical `/init` binary and its associated configuration files are now part of the `/system` partition itself. The `boot.img` is significantly leaner, typically containing only the kernel and Device Tree Blob (DTB) for ARM64 devices, or potentially a ‘stub’ ramdisk for compatibility reasons that quickly pivots to the `system` partition. This integration simplifies the system for GSI compatibility and A/B updates, as the entire core OS is treated as one atomic unit.

Deconstructing the SAR Layout

The `super` Partition and Dynamic Partitions

Central to SAR is the concept of Dynamic Partitions, managed by a `super` partition. The `super` partition is a physical partition that acts as a container for several logical partitions, such as `system`, `vendor`, `product`, `odm`, and `cache`. Instead of these being fixed physical partitions, they are logical volumes allocated dynamically within the `super` partition.

When a SAR device boots, the bootloader mounts the `super` partition, and then the Android `init` process identifies and mounts the logical `system` partition directly as `/`. This means that when you access `/` on a SAR device, you are directly interacting with the contents of the `system` partition.

The `system_root` Filesystem

In a SAR setup, the root of the filesystem is effectively the root of the `system` partition. Internally, Android uses the concept of `system_root` to denote this. The `init` process now looks for its configuration files (e.g., `fstab.post_init` and `init*.rc` files) directly within the `system` partition. This is a crucial distinction: the `/` you see is directly `system`, not a ramdisk that later mounts `system`.

To illustrate the difference, observe the output of the `mount` command on a SAR vs. a non-SAR device:

# On a pre-SAR device

$ adb shell mount | grep

        
        
        

            

                
            
            

                
Android Mobile Specs & Compare Directory
                
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →