Android Architecture Evolution

Android's system architecture has undergone significant restructuring over the past decade. The evolution primarily revolves around decoupling the core OS framework from hardware-specific implementations to streamline updates and improve security.

The Monolithic Era (Pre-Android 8.0)

In early Android versions, the Android Framework and hardware-specific Vendor code were tightly coupled.

Structure

• System Code: The Android OS framework, managed by Google.
• Vendor Code: Hardware Abstraction Layers (HALs) and drivers provided by silicon vendors (Qualcomm, MediaTek) and device manufacturers (OEMs).

The Bottleneck

HALs were implemented as .so (shared object) libraries loaded directly into the memory space of framework processes (like system_server). This tight coupling meant that:

1. Framework dependency: A change in the Android Framework often broke the HALs.
2. Update dependency: Updating the OS required vendors to recompile and adapt their HALs against the new framework APIs.
3. Result: System updates were notoriously slow, taking several months as the code traversed from Google to SoC vendors, then to OEMs, and finally to carriers.

The Modular Era: Project Treble (Android 8.0+)

Introduced in Android 8.0 (Oreo), Project Treble fundamentally re-architected the OS to separate the vendor implementation from the Android OS framework.

The Treble Architecture

Treble introduced a strict boundary between the OS and the hardware via a formalized vendor interface.

1. Partitioning:
   • /system: Contains the generic Android OS framework.
   • /vendor: Contains the device-specific hardware HALs and drivers.
2. HIDL and AIDL: Hardware interfaces were defined using the Hardware Interface Definition Language (HIDL) (and later AIDL). The framework communicates with HALs using these standardized interfaces over binder IPC, rather than loading them directly into process memory (passthrough vs. binderized HALs).
3. VNDK (Vendor Native Development Kit): A set of libraries allowing vendor code to be built against a stable API surface, ensuring compatibility across different Android versions.
4. VINTF (Vendor Interface Object): A manifest system ensuring that a given system image is compatible with the underlying vendor image.

The Impact

By separating the framework from the vendor implementation, Google enabled a Generic System Image (GSI) to boot on any Treble-compliant device. OEMs can now update the Android framework (/system) without needing silicon vendors to rewrite their HALs (/vendor).

The Granular Era: Project Mainline (Android 10+)

While Treble decoupled the OS from the hardware, Project Mainline modularized the OS framework itself.

• APEX Modules: Core system components (like Media Codecs, Network Stack, Conscrypt, and ART) were extracted from the monolithic /system partition and repackaged as APEX (Android Pony EXpress) modules.
• Out-of-band Updates: These modules can be updated directly via Google Play System Updates independently of full OTA (Over-The-Air) firmware updates from the OEM.

Summary

• Pre-Treble: Monolithic structure. Framework and HALs share process space and update cycles.
• Project Treble: Separated /system and /vendor. Standardized communication via HIDL/AIDL.
• Project Mainline: Modularized the /system partition using APEX packages for independent, out-of-band updates.