Linux is a kernel — the piece of software that talks directly to hardware and decides which process gets the CPU, which process can touch which memory, and which process is allowed to do what. It was written by Linus Torvalds starting in 1991 and today runs everything from servers to routers to, since 2008, phones.
A kernel by itself isn't an operating system a person can use — Linux distros (Ubuntu, Debian, Android) add a userland (shells, libraries, apps) on top. Android's userland looks almost nothing like a desktop Linux distro's, but the kernel underneath is recognizably the same Linux kernel, patched for mobile.
The kernel concepts that explain Android behavior
Four Linux primitives, specifically, are worth understanding because Android's app model is built directly on top of them:
- Processes and UIDs — every process runs as some user ID, and the kernel enforces what that UID can access. Android gives every app its own UID, so kernel-level file permissions are the actual sandbox boundary between apps.
- Permissions on files and resources — the classic Unix read/write/execute model. Android's runtime permission dialogs are a userland layer on top of this; the kernel-level enforcement is what makes the sandbox non-optional even if the userland layer had a bug.
- Signals and process lifecycle — SIGKILL, SIGSTOP, fork/exec. Android's app process model (see the next article) is built by forking a template process rather than starting each app from a cold JVM.
- Drivers and the HAL boundary — camera, radio, GPU, sensors — vendor code lives below a stable interface (the Hardware Abstraction Layer) so a kernel/driver update doesn't require every app to be recompiled.
In this note
References & resources