The kernel features Android leans on

A kernel is a large piece of software, and Android uses a small, specific slice of it. That slice is worth knowing by name, because almost every Android behaviour you can observe — why a process cannot read a file, why a camera buffer is shared without a copy, why an app can start before it has finished downloading — resolves to one of about seven facilities.

This page is the inventory. For each one: what problem it solves, what the interface looks like, and what happens without it.

TL;DR#

• Binder is the IPC driver. It passes file descriptors, identifies the calling UID, and supports one-way calls. Everything between apps and system_server goes through it.
• memfd replaced ashmem for shared memory. An anonymous file descriptor that can be sealed, mapped and passed over a socket.
• cgroup v2 and PSI are how the kernel reports pressure and how Android groups processes. lmkd is built on both.
• SELinux turns the UID model into mandatory access control: even root is confined to a domain. seccomp-bpf (glossary definition) restricts which system calls a process may make at all.
• DMA-BUF heaps allocate buffers that can be shared between processes and devices without copying — the basis of the graphics and camera pipelines.
• eBPF lets Android run small verified programs inside the kernel for network accounting and monitoring. EROFS and IncFS are the read-only and incremental filesystems that make modern system images work.

Mental model#

Think of the kernel as a workshop with a fixed set of machines.

There is a conveyor belt (Binder) that moves work orders between benches and can attach small objects to them. There is a shared whiteboard (memfd) that several benches can look at, with a rule that lets you freeze it so nobody writes again. There is a foreman (lmkd) who walks around reading the pressure gauges (PSI) and decides which bench to shut down when the room gets crowded. There is a guard at the door (SELinux and seccomp) who checks not just who you are but what you are allowed to touch. There is a loading dock (DMA-BUF) where a delivery is placed once and read by several benches. And there is a small scripting engine bolted to the wall (eBPF) that can measure what the machines are doing without stopping them.

Each machine exists because the obvious alternative — copying data, trusting the caller, stopping the machine to inspect it — was too slow or too unsafe.

Where the analogy breaks#

The workshop has one guard. A phone has two independent ones. SELinux checks access to objects: may this domain open this file, connect to this socket, use this device node. seccomp checks whether the operation exists at all: may this process call mount or ptrace, ever. They are layered, not alternatives, and a process can be blocked by either.

The analogy also understates how much of this is policy shipped as data. SELinux rules are compiled into a binary policy file, and the interesting questions ("what can the camera daemon read?") are answered by that file rather than by the code.

The big picture#

Two of those partitions matter directly to this page. system_dlkm and vendor_dlkm hold .ko files — the modules that make GKI work — and they are mounted read-only and verified. super is where the dynamic partitions live, created by first-stage init with device-mapper before anything mounts them. Both are examples of a pattern this whole module is about: the kernel's facilities are only useful if the partition layout can deliver the code to use them.

Deep dive#

Binder: IPC that knows who you are#

Most IPC mechanisms give you a byte stream or a message queue. Binder gives you something different: a transaction that carries a target object, a parcel of data, and optionally file descriptors, with the kernel recording the sender's identity.

That identity is the crucial part. When a client calls into a service, the kernel attaches the caller's UID (glossary definition) and PID to the transaction. A system service can then check "is this really the app that owns this package?" without trusting anything the caller said. There is no way to forge it, because the caller never writes it.

Binder also supports one-way transactions, which return immediately and are queued, and reference passing, which lets a service hand a client a handle to another Binder object. Both are used heavily: every registerCallback in the framework gives the service a handle it can call back through.

The device node is traditionally /dev/binder. On newer systems, binderfs can be mounted to create private sets of Binder devices — one binder-control node per mount, from which new devices are requested with an ioctl. That is how containers and virtualised Android instances get their own Binder namespace instead of sharing the host's.¹

memfd: the shared whiteboard#

Shared memory is how Android avoids copying large buffers between processes. The original mechanism was ashmem, an Android-specific driver. It was replaced by memfd_create, a standard system call that returns a file descriptor backed by anonymous memory.

The descriptor is the point. Because it is a file descriptor, it can be:

• mapped with mmap in the creating process,
• passed over a Unix socket to another process, which maps the same pages,
• sealed so that no further writes are possible, which is how a producer hands a buffer to a consumer immutably,
• resized with ftruncate before it is shared.

memfd_create has been in Linux since 3.17. Android's move to it was gradual, because ashmem had a couple of behaviours memfd lacked — notably the ability to make a region read-only for future writes while keeping existing writable mappings alive. Memfd grew seals to cover that, and the ashmem driver was eventually deleted from the kernel.²

The practical consequence for you: a shared-memory bug in an app is now usually a file-descriptor bug. If a descriptor leaks, the memory leaks; if it is passed to the wrong process, that process can read the buffer.

cgroup v2 and PSI: pressure, measured#

Android groups processes into cgroups, and cgroup v2 is a single hierarchy with per-controller files.³ The four controllers that matter:

PSI adds something cgroups do not: a time-based measure of contention. Instead of "this group is using 800 MB", PSI says "tasks in this group spent 12% of the last minute waiting for memory". That is a far better signal for a killer, because it measures the symptom the user feels rather than a proxy for it.⁴

lmkd (glossary definition) combines the two. It watches PSI thresholds, maps them to an urgency level, and kills the least important eligible process — where importance comes from the framework's oom_adj (glossary definition) score. Its thresholds are tunable through ro.lmk.* properties, which is why you will see names like ro.lmk.psi_partial_stall_ms in getprop output on a device.⁵

SELinux: the guard that checks the object#

The UID model says a process can access what its user owns. That is too coarse for Android, where every app has its own UID but the system must still stop a compromised app from reading another app's files even if a bug gave it the wrong UID.

SELinux (glossary definition) adds a second check. Every process runs in a domain; every file, socket and device has a type. The policy says which domain may perform which operation on which type. The kernel checks on every access, and a denial is logged as an AVC message.⁶

Three consequences are worth internalising:

Root is not a bypass. A process running as UID 0 is still confined to its domain. That is why adb root on a production device does not give you the access you expect: the shell domain's policy is narrow.

Policy is compiled, not interpreted. The rules live in a binary policy file loaded at boot, built from .te files in system/sepolicy. A denial at runtime means the policy did not allow the operation, not that a check failed.

Labels are everywhere. Files have labels, sockets have labels, properties have labels, and even Binder services have labels. restorecon exists because a file created at runtime inherits a default label and may need to be relabelled to its intended type.

seccomp-bpf: the guard that checks the verb#

SELinux cannot stop a process from calling a system call that exists in the kernel; it can only stop the call from succeeding on a protected object. seccomp goes further: it filters system calls before they execute.

A process installs a small classic-BPF program that inspects struct seccomp_data — syscall number, arguments, architecture — and returns an action. The actions, in increasing severity:

The program may not dereference pointers. It sees only the raw register values, which is deliberate: seccomp is not a syscall interposer and cannot be tricked by a user-space race on an argument.⁷

There is one precondition that trips people up. To install a filter, the process must either hold CAP_SYS_ADMIN or set PR_SET_NO_NEW_PRIVS. The second is how unprivileged sandboxes do it: no-new-privs promises that nothing this process executes will gain privileges, which is exactly the property that makes it safe to let an unprivileged process constrain itself.

Android uses seccomp widely: the app process, media codecs, and many native daemons run under filters that allow only the syscalls they need. The practical consequence is that an app calling an unusual syscall through JNI can be killed with SIGSYS, and the tombstone will say so.

DMA-BUF heaps: one buffer, many readers#

A camera produces a frame. The GPU may need to process it, the display may need to scan it out, and an encoder may need to compress it. Copying the frame between three subsystems would be ruinous, so Android uses a buffer that is allocated once and shared by reference.

DMA-BUF is the kernel object. DMA-BUF heaps are where the memory comes from. Each heap is a character device:

/dev/dma_heap/system
/dev/dma_heap/system_uncached

A client opens the heap, allocates with an ioctl, and receives a file descriptor for the buffer. That descriptor can be passed to another process over a socket, and each holder maps it or hands it to a driver.

The heap-per-device design is the security improvement over the old ION allocator. With /dev/ion, anything that could open the device could allocate from any heap. With heaps, SELinux can allow a process to use the cached system heap and deny it the uncached one, or allow the camera to allocate but not the display.⁸

In Android 12, GKI 2.0 replaced ION with DMA-BUF heaps, and the android12-5.10 branch disabled CONFIG_ION. The userspace side is libdmabufheap, whose BufferAllocator takes a heap name rather than an ION heap ID.

eBPF: small programs inside the kernel#

eBPF (glossary definition) is a virtual machine inside the kernel. A user-space program compiles a small bytecode program, the kernel verifies it for safety, and it runs attached to a probe or event.

Android uses it for things that would otherwise require a kernel patch:

• Socket filtering and statistics in netd (glossary definition), which is how per-UID network accounting and firewalling work without a separate kernel module.
• time_in_state, which records how long an app spent at each CPU frequency — the basis for power attribution.
• gpu_mem, which tracks GPU memory per process and system-wide.
• Histograms for statsd, collecting memory-management and power latencies at low overhead.⁹

The appeal is that the policy can change without a kernel update. A new firewall rule is a new eBPF program, not a new kernel image. That is the same modularity argument as GKI, applied at a much smaller scale.

The filesystems: EROFS and IncFS#

Two filesystems deserve mention because they changed what a system image can be.

EROFS is a read-only filesystem designed for compression and read performance. Its key trick is in-place decompression: compressed data sits at the end of a block and is expanded into the same page, so reading does not require allocating extra pages. Images are roughly a quarter smaller on average with compression, and reads are fast because there is no write path to maintain. On devices launching with Android 13 it became the default for read-only partitions in the GMS configuration, and as of Android 13 it is fully supported with Virtual A/B.¹⁰

IncFS (Incremental FS) is the filesystem behind incremental app installs. It presents a file whose contents are not yet all present; reads block until the requested page arrives. That is what lets a large game start before it has finished downloading. It arrived in Android 11, and from Android 12 it is built into the kernel rather than loaded as a module.¹¹

How it evolved#

The kernel-facing changes cluster in a few releases. Android 9 added App Standby Buckets and the groundwork for Mainline. Android 10 introduced dynamic partitions and scoped storage. Android 11 brought GKI, incremental installs and DMA-BUF heaps beginning to replace ION. Android 12 made GKI 2.0 mandatory on 5.10 and switched ION off. Android 13 added the system_dlkm partition and made EROFS the default read-only filesystem for new GMS devices.

Notice what is not in that list: new Android-specific kernel drivers. Since GKI, the platform's kernel work goes into the common kernel and the KMI, not into a vendor fork.

Under the hood#

• ‹›lmkd.cpp↗PSI thresholds, cgroup walking and the kill decision
• ‹›init.rc↗the cgroup directories and permissions init sets up at early-init
• ‹›BufferAllocator.cpp↗allocating a DMA-BUF by heap name
• ‹›first_stage_mount.cpp↗mounting verified read-only partitions before /system exists
• ‹›sepolicy↗the policy sources that become the binary policy loaded at boot

Curiosity corner#

• The system heap is cached and system_uncached is not, and the difference is a real performance trade-off: cached memory is faster to re-read but can be reclaimed under pressure.
• A seccomp violation kills the process, not the syscall. There is no exception to catch in Kotlin, because the process is gone before the exception could exist.
• EROFS was created by a Huawei engineer and upstreamed into Linux before Android adopted it — another case of an Android need being met by a general kernel feature.
• Binder's identity guarantee is why Android can have a permission model at all. Any IPC mechanism can pass a message; very few can tell the receiver, with certainty, who sent it.

Try it#

$ 
adb shell cat /proc/meminfo | head -3
adb shell cat /proc/pressure/memory
adb shell ls /dev/dma_heap/
adb shell cat /proc/misc | grep binder
adb shell mount | grep -E "erofs|ext4" | head

MemTotal:        7643212 kB
MemAvailable:    2103444 kB
some avg10=0.42 avg60=0.31 avg300=0.18 total=4823911
system  cached
system-uncached  cacheable
binder 507904 0
hwbinder 507904 0
vndbinder 507904 0
erofs
ext4

/proc/misc is the fastest way to see which Binder devices exist; each one is a separate domain with its own SELinux label. /dev/dma_heap/ shows which heaps the device exposes — a device with only system and system-uncached is not exposing a hardware-specific heap, which is normal for many phones.

Build it#

The N04 lab builds a minimal HAL service and shows the other side of the Binder boundary: a vendor process publishing an interface that a framework client can call. It is the most concrete way to see how the kernel's IPC facility becomes a platform contract.

Check yourself#

Sources#