Modern Android OS Architecture: Linux Kernel, GMS Modules & OEM Skins Explained

Android powers billions of devices globally, spanning compact smartphones, foldables, and specialized computing hardware. Beneath diverse manufacturer interfaces lies a layered software stack built on top of the open-source Linux kernel.

Understanding how Android functions helps clarify why devices with identical silicon can perform differently in memory retention, background processing, and battery longevity.

1. The Multi-Tier Android Architectural Stack

• The Linux Kernel: Manages low-level hardware interactions, thread scheduling, power profiles, and physical device memory.
• Hardware Abstraction Layer (HAL): Standardizes hardware driver calls so the upper application framework can request camera frames or GPS coordinates without knowing the specific vendor sensor model.
• Android Runtime (ART): Compiles application bytecode into native machine instructions via Ahead-of-Time (AOT) and Just-in-Time (JIT) compilation, optimizing frequently used execution paths while maintaining small app footprints.

2. Project Treble: Decoupling the OS Framework from Vendor Hardware

Before Android 8.0 (Oreo), the Hardware Abstraction Layer described in Section 1 was tightly bound to each OEM’s specific Android build. Updating the OS framework often meant rebuilding and requalifying an entire chipset vendor’s drivers alongside it — a major reason updates historically took months to reach devices, or never arrived at all.

Project Treble addressed this by introducing a stable Vendor Interface (VINTF) between the Android OS framework and the underlying vendor implementation:

Pre-Treble:                          Post-Treble:
[ Android Framework ]                [ Android Framework ]
        | (tightly coupled)                  | (stable VINTF)
[ Vendor HAL + Kernel ]               [ Vendor Interface  ]
                                              |
                                      [ Vendor HAL + Kernel ]

• Independent Update Cycles: With a stable, versioned interface between framework and vendor code, an OEM can update the Android OS framework without requiring the chipset vendor to simultaneously rebuild every low-level driver.
• Generic System Images (GSI): Treble compliance allows a standardized, unmodified Android build to run on compliant hardware, which is primarily how independent testing and certification of the framework layer became possible across a fragmented device landscape.

Treble and the Project Mainline modular updates described later in this article solve related but distinct problems: Treble separates the OS framework from vendor-specific hardware code, while Mainline (via Google Play system updates) further breaks the framework itself into independently updatable modules. Together they explain why a modern Android device can receive security patches without a full vendor-signed OTA reboot.

3. AOSP vs. Google Mobile Services (GMS)

A common misconception is that Android and Google are strictly inseparable. The operating system operates on two distinct layers:

1. Android Open Source Project (AOSP): The open-source core containing the kernel patches, base runtime, networking stack, and foundational UI framework. Anyone can fork, modify, and build upon AOSP without Google licensing.
2. Google Mobile Services (GMS): A proprietary suite of cloud services, APIs, and applications licensed to hardware manufacturers. GMS includes Google Play Services (push notifications, location fusion, Play Integrity), the Google Play Store, and core Google applications.

Without GMS certification, devices lack access to safety verification APIs required by modern banking apps and streaming DRM platforms (Widevine L1).

4. OEM Skin Philosophies: Stock vs. Heavy Customization

While the base operating system is standardized, manufacturers alter how memory management, background services, and design languages are implemented:

Why RAM Management Varies Across Brands

Different OEMs configure how aggressively the system terminates background processes. While a device with 12 GB of RAM on stock Android might keep 15 apps cached in memory indefinitely, aggressive third-party battery optimization suites may kill background tasks after a few minutes of screen-off time.

For pro users and developers, understanding an OEM’s background policy is just as vital as reviewing raw hardware specifications.

Related Smartphone Reviews & Hardware Analysis

• Pixel Hardware Architecture: Read our deep dive on Google Custom Silicon & Tensor TPUs.
• Full Product Matrix: Compare current flagships side-by-side in our Google Pixel 11 Family Breakdown.