Introduction: The Android Boot Conundrum

The Android boot process, particularly on modern devices utilizing the System-as-Root (SAR) partition layout, can appear intricate. At its heart lies the initramfs, often referred to as the ramdisk, a critical component that bridges the gap between the hardware initialization and the full operating system startup. This article delves deep into the evolution and function of initramfs, specifically its pivotal role in devices employing SAR, and provides a practical guide to understanding its inner workings.

Understanding Initramfs: The Kernel’s First Steps

Traditionally, initramfs (initial RAM filesystem) is a minimal root filesystem loaded into RAM before the actual root filesystem on persistent storage is mounted. Its primary purpose is to provide the necessary utilities and kernel modules to perform this critical mount operation. Without it, the kernel wouldn’t know how to access the storage device containing the ‘real’ root filesystem (e.g., ext4, f2fs on an eMMC or UFS chip).

In a non-SAR Android setup, the `boot.img` typically contains both the kernel and a ramdisk. This ramdisk is responsible for setting up the initial environment, identifying and mounting the `/system` partition, and then pivoting the root to `/system`. Once `/system` is mounted, the `init` process from `/system/bin/init` takes over.

The Paradigm Shift: Android’s System-as-Root (SAR)

System-as-Root is a significant architectural change introduced in Android 9 Pie and mandated for devices launching with Android 10 and later. In SAR, the `/system` partition is no longer a separate, mountable entity but rather becomes the root filesystem (`/`) directly. This design simplifies updates, improves security, and streamlines the A/B update mechanism by consolidating the root into a single partition.

Key characteristics of SAR:

• The `/system` partition is mounted as the root (`/`).
• There is no longer a separate `/vendor` partition in terms of mounting structure; `/vendor` is a directory within the root filesystem.
• The `boot.img` typically contains only the kernel (or a `kernel` partition). The ramdisk is moved to a dedicated `init_boot.img` or embedded within the `boot.img` in a more complex structure, depending on the device and Android version.

Initramfs in a System-as-Root World

With SAR, the role of initramfs evolves. Since `/system` *is* the root, the initramfs’s job is to prepare the environment to mount this combined system/root partition directly. The ramdisk typically found within `init_boot.img` (or `boot.img` on older SAR implementations) now contains the initial `init` executable, device trees, and other crucial files needed to bring up the core system.

The `init` process within the ramdisk is responsible for:

1. Initializing necessary device drivers.
2. Setting up early userspace environment.
3. Mounting the physical partition that contains the combined system/root filesystem. This is often `rootfs` or `system` on the underlying block device (e.g., `/dev/block/by-name/system`).
4. Executing the `init` binary from the newly mounted system partition, which then takes over the boot process.

Anatomy of a SAR Initramfs

Let’s look at the critical files you’d find inside a SAR initramfs:

• `init`: The very first userspace process, responsible for orchestrating the rest of the boot.
• `fstab.`: Defines the filesystems to be mounted, including the SAR partition.
• `ueventd.rc`: Rules for device node creation.
• `vendor_init.rc` (or similar): Device-specific initialization scripts.
• `verity_key`: Used for dm-verity verification.
• Various binaries and libraries: Tools like `toolbox`, `sh`, and necessary shared libraries (`libc.so`, etc.).

Practical Deep Dive: Analyzing a SAR Initramfs

To truly understand initramfs, let’s get hands-on. We’ll examine how to extract and inspect a modern Android `boot.img` or `init_boot.img` (for devices with a separate `init_boot` partition).

Step 1: Obtain Your Device’s Boot Image

First, you need the `boot.img` or `init_boot.img` from your device. This can often be found in official factory images or custom ROM packages.

Step 2: Unpack the Boot Image

Tools like `AIK-Android` (Android Image Kitchen) or `magiskboot` are invaluable here. For `magiskboot`, assuming you have extracted it from a Magisk APK:

./magiskboot unpack boot.img

This command will typically extract the kernel, ramdisk, and other components into separate files:

• `kernel`: The Linux kernel.
• `ramdisk.cpio`: The compressed cpio archive containing the initramfs.
• `dtb`: Device Tree Blob (if present).

If your device uses a separate `init_boot.img` (common on newer devices, especially with GKI):

./magiskboot unpack init_boot.img

This will give you `ramdisk.cpio` (the actual initramfs), and potentially `dtb`. The kernel is on a separate `kernel` partition in this scenario.

Step 3: Extract the Ramdisk

Now, extract the contents of `ramdisk.cpio`:

mkdir ramdisk_contents cd ramdisk_contents cpio -idm < ../ramdisk.cpio

Step 4: Inspect Key Files

Once extracted, navigate into `ramdisk_contents`. Look for files like `init`, `fstab.qcom` (or `fstab.mtk`, etc.), and `.rc` scripts.

Example: `init` script logic (simplified)

A crucial part of the `init` binary in the ramdisk is to find and mount the SAR partition. The `fstab` file guides this process. For instance, an `fstab` entry for a SAR device might look like this:

/dev/block/by-name/system / ext4 ro,barrier=1,discard wait,verify

The `init` binary parses this, locates the `system` block device, and mounts it as the root (`/`). After this, it performs a `pivot_root` or `exec` call to transition to the `init` binary residing on the newly mounted root filesystem.

The `init.rc` or `first_stage_init.rc` scripts within the ramdisk will contain commands like:

mount_all /fstab.${ro.hardware} # or similar command to mount partitions copy /init /sbin/init # copy early init to final destination exec /sbin/init # execute the real init from system

In SAR, `mount_all` mounts `/system` directly as `/`. The subsequent `exec /init` (or `/system/bin/init` depending on exact setup) then hands control to the `init` process of the main Android system.

Impact on Custom Development (Rooting/Flashing)

The SAR architecture profoundly impacts custom development, especially rooting and custom ROM flashing:

1. Boot Image Patching: Since the kernel and ramdisk might be separated (`kernel` and `init_boot` partitions), patching tools like Magisk need to adapt. Magisk often patches the `init_boot.img` (or `boot.img` if unified) to inject its `magiskd` binary and modify the ramdisk’s `init` script to launch Magisk’s early userspace.
2. Recovery: Custom recoveries like TWRP must also be SAR-aware, understanding how to mount the root filesystem correctly to perform backups and restores.
3. Flashing: Flashing a new system image directly replaces the root partition, streamlining updates but requiring careful handling of vendor interfaces.

Conclusion

The initramfs, or ramdisk, remains an indispensable component of the Android boot process. Its evolution from a simple pre-mounter to a sophisticated early boot orchestrator in the System-as-Root era highlights Android’s continuous drive towards efficiency, security, and updateability. By understanding its inner workings and the critical role it plays in mounting the SAR partition, developers and enthusiasts alike can gain deeper insights into the foundation of modern Android devices, paving the way for more robust custom modifications and system optimizations.