Why Android Chooses Binder for IPC: Performance, Stability, and Security Explained

1. Concept

Binder is an inter‑process communication (IPC) mechanism.

2. Why Android Chooses Binder

Android, built on the Linux kernel, already provides IPC mechanisms such as pipes, message queues, shared memory, and sockets. Android adopts Binder primarily for performance, stability, and security reasons.

Performance

General IPC interfaces like sockets have low transmission efficiency and high overhead. Message queues and pipes use a store‑and‑forward approach, requiring at least two memory copies (user → kernel → user). Shared memory avoids copies but is complex to manage. Binder needs only a single data copy, offering performance just behind shared memory.

Stability

Binder follows a client‑server architecture; the client’s requests are handled by the server, providing clear responsibilities and independence, which enhances stability compared to shared memory.

Security

Android assigns a unique UID to each installed app, using this UID as a reliable identity marker. Traditional IPC lacks such built‑in identity verification, making it vulnerable. Binder incorporates UID/PID checks in the kernel and supports both named and anonymous binders, greatly improving security.

Traditional Linux IPC Principles

Process isolation means processes cannot directly access each other’s memory, requiring IPC mechanisms. The OS divides virtual address space into user space and kernel space; the kernel (top 1 GB) and user processes (lower 3 GB) are separated. System calls are the only way for user space to access kernel resources safely.

Traditional IPC Workflow

Data is placed in a user‑space buffer, copied to a kernel buffer via copy_from_user(), then copied back to the receiving process’s user buffer via copy_to_user(), resulting in two memory copies.

Drawbacks of Traditional IPC

Low performance due to multiple memory copies.

Receiver must allocate a buffer without knowing the exact data size, leading to wasted space or extra steps.

Binder IPC Mechanism

Key Concepts

Dynamic Kernel Loadable Module : The Binder driver is a kernel module that bridges user processes for communication.

Memory Mapping : Binder uses mmap() to map a user‑space memory region to kernel space, reducing data copies.

Binder Implementation Steps

The Binder driver creates a data reception buffer in kernel space.

A kernel buffer is allocated and mapped to both the driver’s reception buffer and the client’s user‑space address.

The sending process copies data to the kernel buffer via copy_from_user(); due to the memory mapping, the data becomes directly visible to the receiving process’s user space, completing the IPC.

Binder Communication Process

A complete IPC involves at least two processes: a client and a server, which communicate via the Binder driver.

Components

Client, Server, ServiceManager, and the Binder driver. Client, Server, and ServiceManager run in user space; the Binder driver runs in kernel space. Communication occurs through system calls open, mmap, and ioctl on /dev/binder.

Binder Communication Steps

The process registers itself as ServiceManager using the BINDER_SET_CONTEXT_MGR command.

The server registers its Binder object with ServiceManager; the driver creates a kernel entity node and ServiceManager stores a reference.

The client obtains the Binder reference from ServiceManager and communicates with the server through the driver.