The Linux Kernel Relationship

Android is built on top of the Linux kernel, but it is a common misconception that Android is a standard Linux distribution. While it shares the same core, the kernel used on an Android device has historically been heavily modified to support the unique constraints of mobile hardware.

Android's Linux Kernel Fork

Google does not use the mainline Linux kernel directly (the kernel developed by Linus Torvalds and the open-source community at kernel.org). Instead, Google maintains its own fork known as the Android Common Kernel (ACK).

Why did Android fork Linux?

Mobile devices have drastically different requirements compared to traditional servers or desktop PCs:

1. Aggressive Power Management: A server expects to be awake 100% of the time. A phone expects to be asleep 99% of the time to save battery, waking up only for specific events (like receiving a network packet).
2. Strict Memory Constraints: Early Android devices had severe memory limits and lacked traditional swap space.
3. Out-of-Tree Drivers: Silicon vendors (Qualcomm, Exynos) frequently wrote proprietary hardware drivers that were not accepted into the mainline Linux kernel.

Android-Specific Kernel Patches

To address these mobile-specific needs, Google introduced several critical subsystems into the Android Common Kernel. Some of the most famous Android-specific patches include:

• Binder: An incredibly fast, highly secure Inter-Process Communication (IPC) mechanism. It is the absolute backbone of Android, allowing the Java framework to talk to native services and HALs.
• Wakelocks: A power management system that prevents the system from entering deep sleep while critical tasks (like playing music or downloading a file) are running.
• Low Memory Killer (LMK): A highly aggressive daemon that kills background processes based on priority scores (oom_score_adj) when the system runs out of RAM, preventing the device from freezing.
• Ashmem: Anonymous Shared Memory, a specialized memory allocation mechanism that allows processes to share memory buffers efficiently.

Over the years, many of these Android-specific patches (like Binder and Wakelocks) have actually been merged upstream into the mainline Linux kernel, bringing Android closer to standard Linux.

You can view the specific Android kernel modules loaded on a device:

adb shell lsmod

The Problem: Kernel Fragmentation

Historically, the path from mainline Linux to an actual Android phone looked like this:

1. Mainline Linux: LTS (Long Term Support) release is published.
2. Android Common Kernel (ACK): Google takes the LTS kernel and adds Android patches (Binder, Wakelocks).
3. SoC Vendor Kernel: Qualcomm or MediaTek takes the ACK and adds hundreds of proprietary patches for their specific chips (CPU, GPU).
4. Device Kernel: Samsung or Google Pixel takes the SoC kernel and adds more patches for device-specific hardware (display panels, cameras, sensors).

The Result: The kernel on a consumer Android phone was a highly fragmented, heavily patched Frankenstein. It was impossible to update the kernel without extreme engineering effort, trapping devices on outdated, insecure kernel versions forever.

The Solution: Generic Kernel Image (GKI)

To solve the extreme kernel fragmentation, Google introduced the Generic Kernel Image (GKI) starting with Android 11, and enforced it strictly in Android 12.

How GKI Works

GKI is similar in philosophy to Project Treble, but applied to the kernel:

1. Strict Modularization: Device-specific and SoC-specific hardware drivers are no longer allowed to be hardcoded directly into the core kernel binary (vmlinux).
2. Loadable Kernel Modules (LKMs): Vendors must compile their proprietary drivers as separate kernel modules (.ko files).
3. Stable KMI: Google guarantees a stable Kernel Module Interface (KMI). As long as a vendor module is built against this interface, it will work.
4. The Result: Google can deliver a single, pre-compiled generic kernel binary (boot.img) that boots on any modern Android device, dynamically loading the vendor's .ko modules at runtime.

Why GKI Matters for AOSP

With GKI, Google can update the core Linux kernel on consumer devices via Play System Updates or standard OTAs without needing the silicon vendor to rewrite their drivers. This vastly improves device security, prolongs the device's lifespan, and makes custom ROM development significantly easier.

# Example of building a Kernel Module for GKI
obj-m += my_vendor_driver.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules