Understanding Android Binder IPC: Service Manager Startup, Client Registration, and Core Data Structures

This article provides a detailed technical overview of the Android Binder inter‑process communication (IPC) mechanism, covering the startup of the Service Manager, how clients locate it, the registration of service components, and the key kernel data structures involved.

Startup : During Android system boot, the init process launches the Service Manager. The Service Manager opens /dev/binder , causing the kernel to create a binder_proc object that represents the process in the Binder subsystem. A 128 KB shared memory region is mapped for communication, the process is set as the context_manager (a name‑server for service names), and it enters a read‑blocking state awaiting requests.

Kernel data structures after startup : The article lists the members of struct binder_proc , including a list node for the global binder_procs list, red‑black trees for threads and nodes, a waiting‑threads list, PID, task descriptor, todo list, thread‑pool limits, a binder_alloc allocator, and a binder_context that holds the global context manager.

Process abstraction : Each Binder‑using process is represented by a binder_proc and a single binder_thread . The thread performs the actual communication, while the proc aggregates resources such as threads, nodes, and memory.

binder_thread structure : Important fields include a pointer to its owning binder_proc , a red‑black‑tree node, a waiting‑thread list node, thread ID, the current transaction stack, and a pointer to the user‑space task_struct .

binder_node structure : Represents the kernel counterpart of a user‑space service component. Key members are a red‑black‑tree node, a back‑pointer to its binder_proc , a debug ID, a hash table of references ( binder_ref ), and a pointer to the user‑space service object.

Client locating Service Manager : A client opens the Binder driver, which creates its own binder_proc and maps the shared memory. It then issues an ioctl with handle 0 (the reserved handle for the Service Manager). The kernel resolves this to the Service Manager’s binder_node via the context manager.

Service registration flow : The client builds a user‑space service object and sends a BC_TRANSACTION with the add_service code. The driver creates a binder_node for the service, a binder_ref linking the node to the Service Manager’s proc, and assigns a handle that the client can use for future calls.

Transaction handling : The article describes struct binder_transaction and its associated binder_work . Fields include source and destination processes/threads, a buffer pointer, operation code, flags, sender PID/EUID, and data size information. The transaction lifecycle involves creating a binder_work item, queuing it on the target thread’s todo list, and waking the thread to process the request.

Memory operations : When a client initiates a transaction, it builds a binder_transaction_data buffer (data + offsets) in user space and copies it to the kernel. The kernel allocates a VMA in the target process, maps the shared buffer, and copies data only once. Subsequent reads/writes use the already‑mapped buffer without additional copies.

Key allocator structures : The binder_alloc structure tracks the VMA, the overall buffer pool, free and allocated buffers (organized in red‑black trees), and asynchronous space. binder_buffer entries link to the allocator, the owning transaction, target node, and store sizes for data and offset regions.

Overall, the article serves as a comprehensive reference for developers and engineers working on low‑level Android system components, providing insight into how Binder IPC is initialized, how services are registered, and how data is transferred between processes.