Binder ipc and threading

<- Back to AOSP

Binder IPC and Threading Deep Dive

Overview

Binder is Android's primary inter-process communication mechanism. It gives Android system services and apps a typed RPC layer with kernel arbitration, identity propagation, and predictable lifecycle behavior.

Transaction lifecycle

1. Client calls a generated proxy method.
2. Proxy writes arguments into a Parcel.
3. Userspace performs ioctl on /dev/binder.
4. Binder driver enqueues work for target process.
5. Target binder thread dequeues and calls the server stub.
6. Result is marshalled and returned through the driver.

Thread pool behavior

Binder thread pools are per-process. Throughput and tail latency depend on:

• number of worker threads
• lock contention in handlers
• synchronous nested binder calls
• amount of parcel marshalling work

Common failure modes

• binder thread starvation due to long-running handlers
• large parcel payloads adding copy and parse cost
• deadlocks from lock order inversion across services
• cascading latency from synchronous service-to-service call chains

Practical mitigation patterns

• keep binder entry points short and non-blocking
• hand off heavy work to dedicated executors
• avoid nested synchronous binder chains in hot paths
• enforce payload size budgets and paging/chunking
• add timeout, retries, and fallback at API boundaries

Observability and debugging

Use Perfetto to correlate caller and callee time:

• binder transaction trace slices
• scheduler run queues and preemption
• lock contention in service process
• p95 and p99 latency by binder method

Interview guidance

A strong answer should include:

• kernel + userspace flow, not only high-level concept
• binder thread pool tradeoffs under load
• one concrete tail-latency debugging workflow
• one reliability mechanism like death recipients