Binder Thread Pool Limits and Latency Under Concurrent Transactions

Binder Thread Pool Saturation

Android’s Binder driver exposes a per‑process thread pool whose default size is 16 threads. When an application issues more concurrent IBinder.transact() calls than the pool can service, the excess transactions are queued by the kernel rather than rejected. This queuing introduces latency that is invisible in sequential benchmarks but can become significant under bursty workloads.

The framework constant that defines the pool size is not exposed via the public SDK, and the exact scheduling policy for queued transactions—whether it follows a strict FIFO order or is influenced by thread priority—is not documented. Consequently, architects lack a definitive worst‑case latency model for concurrent Binder traffic.

What is the precise scheduling policy applied to queued Binder transactions when the thread pool is saturated? Does the queue maintain a strict FIFO order, or does it consider thread priority or other factors? Can the pool size be altered through system properties or is it fixed per process for all builds?