Operating Systems - Android Architecture & Case Study

Android is the world's most widely deployed operating system, running on over three billion devices ranging from smartphones and wearables to automotive cockpits, tablets, and desktop workstations.

Rather than a conventional Linux distribution ("GNU/Linux"), Android is a specialized, battery-aware, capability-sandboxed operating system built on top of a modified Linux kernel.

Why GNU/Linux Was Unsuitable for Mobile

When Android was engineered in the mid-2000s, standard desktop/server Linux could not run effectively on mobile hardware:

  1. Strict Power & Thermal Budgets: Desktop operating systems assume an uninterrupted wall-power supply or large laptop batteries. Mobile devices require aggressive energy-aware scheduling, instantaneous peripheral sleep, and wakelocks.
  2. NAND Flash Endurance & Zero Physical Swap: Desktop OSs rely on disk swap partitions to survive memory exhaustion. Swapping to raw flash memory rapidly degrades NAND silicon and introduces severe latency spikes.
  3. Hostile Multi-Tenant App Model: On traditional desktop Unix/Linux, all applications launched by a user run under that user's identity (UID 1000) and can read each other's files in $HOME. Mobile platforms execute untrusted, third-party software that must be strictly quarantined from other apps.
  4. Display Tearing & Touch Latency: The legacy X11 display server suffered from tearing, high overhead, and lacked synchronization with display refresh hardware, making fluid 60 Hz touch manipulation impossible.

To overcome these physical limitations, Android engineered specialized kernel drivers and userspace subsystems that fundamentally diverged from traditional Unix architectures.

Architecture: From Bare Metal to Application

+-------------------------------------------------------------------------+
|                           Applications Layer                            |
|             (System Apps, Third-Party Apps, Workstation UIs)            |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                        Java / Kotlin Framework                          |
|    (ActivityManager, WindowManager, PackageManager, View System)        |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  Android Runtime (ART) & Native Daemons                 |
|     - ART (AOT / JIT / Cloud Profiles)    - SurfaceFlinger (Compositor) |
|     - Bionic libc (Lightweight C Lib)     - lmkd (Low Memory Killer)    |
|     - Rust Native Security Daemons        - servicemanager (Binder)     |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                    Hardware Abstraction Layer (HAL)                     |
|         (Camera, Audio, Sensors, Gralloc, Hardware Composer HWC)        |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                       The Linux Kernel (ACK / GKI)                      |
|     - Binder IPC Driver (/dev/binder)     - Energy Aware Scheduler (EAS)|
|     - ZRAM with zsmalloc                  - Protected KVM (pKVM / AVF)  |
|     - dm-verity / AVB (Verified Boot)     - F2FS & EROFS Filesystems    |
+-------------------------------------------------------------------------+

The Linux Kernel & Generic Kernel Image (GKI)

The Android kernel is an offshoot of upstream Linux Long-Term Supported (LTS) releases called the Android Common Kernel (ACK).

Solving Kernel Fragmentation: GKI 2.0

Historically, hardware vendors (SoC manufacturers and device OEMs) branched the kernel and added thousands of proprietary out-of-tree patches, creating severe fragmentation and delaying security patches.

Google solved this with the Generic Kernel Image (GKI) initiative (standardized in Android 12+):

+-------------------------------------------------------------+
|                 Generic Kernel Image (GKI)                  |
|         (Google-Built, Signed, Unified Linux Kernel)        |
+-------------------------------------------------------------+
|                Kernel Module Interface (KMI)                |
|           (Stable, Versioned In-Kernel Driver ABI)          |
+-------------------------------------------------------------+
|        Vendor Modules (SoC)       |       ODM Modules       |
|    (Qualcomm/MediaTek Display)    |   (Camera, Audio, USB)  |
+-------------------------------------------------------------+
  • Unified Core: Google compiles and signs a single boot.img kernel that boots across all compliant hardware.
  • Kernel Module Interface (KMI): A frozen, version-controlled ABI enabling chipmakers to ship vendor-specific hardware drivers as Loadable Kernel Modules (LKMs) without modifying the core kernel source.

Inter-Process Communication: The Binder Architecture

Traditional Linux IPC relies on Unix domain sockets, pipes, shared memory, and D-Bus. Android routes over 90% of its system interactions through Binder (/dev/binder).

Why Binder?

Feature Standard Unix IPC / D-Bus Android Binder IPC
Data Copy Overhead Double-Copy: User A -> Kernel Buffer -> User B. Single-Copy: Kernel directly memory-maps target process memory via mmap().
Scheduling Priority Target thread runs at its own fixed priority. Priority Inheritance: Server thread elevates priority to match the caller, preventing UI thread starvation.
Security Tokens Relies on manual credential passing via getsockopt. Automatic, unforgeable PID/UID verification handled inside the kernel driver.
Reference Counting Manual application-level management. Distributed, cross-process object reference counting (cleans up dead endpoints automatically).

Binder Under the Hood

When an application calls a remote system service (e.g., querying GPS location from LocationManagerService):

  1. Parcel Marshalling: Arguments are serialized into a flat memory buffer called a Parcel.
  2. ioctl Transaction: The client issues an ioctl(binder_fd, BINDER_WRITE_READ, ...) system call.
  3. Zero-Copy Memory Mapping: The kernel driver copies the parcel memory directly into the address space of the receiving server process, which was previously configured with mmap().
  4. Execution in Thread Pool: A dedicated worker thread from the server's Binder thread pool handles the transaction and writes the response parcel back to the client.

Memory Architecture: Zero-Swap & Low Memory Killer

Mobile hardware has no physical swap partition on disk. Writing heavily to NAND flash causes physical wear, burns battery power, and introduces interactive stuttering.

1. ZRAM with zsmalloc

Android uses ZRAM, a compressed RAM block device:

[ Physical RAM (e.g. 8GB) ]
+---------------------------------------+-----------------------------+
| Active Application Memory (Uncompressed)| ZRAM Compressed Swap (RAM)  |
| - ART Heap Objects                    | Inactive pages compressed   |
| - Graphic Buffers                     | via LZ4 / zstd (2x-3x ratio)|
+---------------------------------------+-----------------------------+

When physical pages become inactive, the kernel swaps them into ZRAM instead of flash storage. Algorithms like LZ4 or zstd compress memory in microseconds, effectively multiplying available RAM by 2x to 3x with minimal CPU overhead.

2. Userspace Low Memory Killer (lmkd)

Unlike desktop OSs where processes run until physical memory is exhausted (triggering kernel panic or an arbitrary OOM killer), Android aggressively reclaims memory using lmkd:

  • Pressure Stall Information (PSI): lmkd reads kernel PSI metrics to detect when CPU, memory, or I/O pressure stalls exceed acceptable thresholds.
  • oom_adj_score Hierarchy: When memory drops below critical watermarks, lmkd kills processes in strict reverse order of user importance:
Kill Order:
1. Cached Background Apps (oom_score 900–999)   --> KILLED FIRST
2. Previous Apps (oom_score 700–899)
3. Background Services (oom_score 500–699)
4. Perceptible Background Audio/Nav (oom_score 200–499)
5. Foreground Active App (oom_score 0–199)
6. Native System Daemons (SurfaceFlinger, init) --> NEVER KILLED

Security Model: Per-Application UID Sandboxing

Android inverted the classic Unix user model:

  • Unix Desktop Model: Multiple human users share one machine. All software launched by user "Alice" shares UID 1000. If Alice downloads a malicious binary, it can inspect her browser cookies, read her SSH keys, and delete her files.
  • Android Sandboxing: The device has one human user, but every installed application is assigned its own unique, isolated Linux UID/GID (e.g. u0_a145).
+-----------------------------------+-----------------------------------+
|       Application A (UID 10145)   |       Application B (UID 10146)   |
|   - Private data: /data/data/appA |   - Private data: /data/data/appB |
|   - Linux file permission: 0700   |   - Linux file permission: 0700   |
+-----------------------------------+-----------------------------------+
                  |                                   |
                  v                                   v
+-----------------------------------------------------------------------+
|                    Linux Kernel Process Boundaries                    |
|       (App B cannot ptrace, signal, or read memory of App A)          |
+-----------------------------------------------------------------------+

Defense in Depth

  1. SELinux (Mandatory Access Control): Operates in strict Enforcing mode. Even if an attacker achieves root privileges within an application process, SELinux policy rules prevent that process from modifying system partitions or communicating with unauthorized hardware nodes.
  2. Android Verified Boot (AVB) & dm-verity: Cryptographic trust chain rooted in hardware ROM. The kernel verifies the cryptographic hash tree of every block read from /system and /vendor. Tampered system blocks trigger an immediate kernel freeze.
  3. Platform Rust Migration: Over 70% of historical Android CVEs were memory safety bugs in native C/C++ services. Google migrated high-risk system services—including the Bluetooth stack, Android Keystore, Ultra-Wideband (UWB), and DNS-over-HTTP/3—to Rust, reducing memory safety vulnerabilities across the platform by over 75%.

Graphics & Display Pipeline: SurfaceFlinger

To deliver fluid 60 Hz to 120 Hz displays without visual stutter (jank) or frame tearing, Android bypasses X11 in favor of a specialized graphics stack:

[ App UI (Skia / Vulkan) ] ---> [ Render to Gralloc GraphicBuffer ]
                                                |
                                                v
[ SurfaceFlinger ] <------------- [ VSYNC Interrupt from Display ]
         |
         +---> [ Hardware Composer (HWC) ] ---> [ Display Hardware ]
         |     (Direct hardware plane overlay; zero GPU copy)
         v
[ GPU Fallback Composition ] (Only if display layers exceed hardware planes)
  1. Triple Buffering: Maintains three image buffers (Front, Back, and Render buffer) to ensure the GPU and CPU never stall waiting for a display scanout to finish.
  2. VSYNC Coordination (Choreographer): Synchronizes app frame production, compositor blending, and panel refresh rates, eliminating frame drops.
  3. Hardware Composer (HWC): Offloads layer composition directly to dedicated hardware display overlays (planes), eliminating GPU rendering power consumption during static screen updates.

Evolution From Mobile to Desktop & Workstation

Android is no longer purely a smartphone operating system. Modern iterations (Android 14, 15, and 16) have evolved to support tablets, foldables, automotive dashboards, and full desktop workstations (Samsung DeX, Pixel Desktop Mode):

1. Freeform Window Management

Early Android enforced a rigid, full-screen activity stack (ActivityRecord). Modern Android incorporates a desktop windowing pipeline:

  • Freeform Windowing: Allows overlapping, resizable application windows with min/max/close controls and window snapping.
  • Multi-Display & Multi-Instance: Apps can render across external 4K monitors while processing mouse cursor capture, hover states, and physical keyboard shortcuts.

2. Android Virtualization Framework (AVF)

One of the most consequential additions to modern Android is the Android Virtualization Framework (AVF), introduced in Android 13:

+-----------------------------------+-----------------------------------+
|      Android Host OS (Linux)      |    Guest OS (Microdroid / Linux)  |
|  - SurfaceFlinger                 |  - Minimal stripped Linux kernel  |
|  - ART Framework                  |  - Confidential workloads         |
|  - Android Apps                   |  - Linux Desktop / CLI utilities  |
+-----------------------------------+-----------------------------------+
                  \                                   /
                   v                                 v
+-----------------------------------------------------------------------+
|                    Protected KVM Hypervisor (pKVM)                    |
|           (Hardware memory encryption & isolation at EL2)             |
+-----------------------------------------------------------------------+
|                        Bare-Metal ARM Silicon                         |
+-----------------------------------------------------------------------+
  • Protected KVM (pKVM): A lightweight, formally verified hypervisor running at ARM Exception Level 2 (EL2).
  • Microdroid: A minimal, stripped-down Linux environment that boots in milliseconds inside a hardware-isolated VM.
  • Enterprise & Desktop Computing: AVF allows Android desktop devices to securely execute standard Linux applications and confidential workloads side-by-side with Android without compromising host security.

Architectural Comparison Matrix

Dimension GNU / Desktop Linux Apple macOS / iOS Android OS Windows
Kernel Type Monolithic (Linux) Hybrid (XNU: Mach microkernel + BSD) Monolithic (Linux ACK + GKI) Hybrid (NT Kernel)
C Standard Library GNU glibc Apple libSystem (BSD) Bionic libc Microsoft MSVCRT / UCRT
Primary IPC Sockets, Pipes, D-Bus Mach Messages, XPC Binder (/dev/binder) ALPC, COM / RPC
App Security Model User-level DAC (UID 1000) App Sandbox + Entitlements Per-App Linux UID/GID Sandboxing Integrity Levels + UAC
Out-Of-Memory Strategy Disk Swap + Kernel OOM Compressed Memory + Jetsam ZRAM + Userspace lmkd (PSI) Pagefile + Virtual Memory Manager
Display Server X11 / Wayland Quartz Compositor (WindowServer) SurfaceFlinger + HWC Desktop Window Manager (DWM)
Virtualization KVM / QEMU Hypervisor.framework Protected KVM (pKVM / AVF) Hyper-V
UNIX ClassicSponsored
The Design of the UNIX Operating System
Kernel Architecture
The Design of the UNIX Operating System
By Maurice J. BachView on Amazon