Android IPC (Binder)
Also known as: binder ipc, android inter process, android binder ipc
Binder is Android's core inter-process communication (IPC) mechanism—a kernel driver and userspace framework that lets an app's process call methods in system services like the media store across process boundaries.
- Binder is a `/dev/binder` kernel driver plus a userspace framework underlying ContentResolver, PackageManager, and MediaStore calls.
- Transactions share a per-process buffer of about 1 MB—oversized results throw TransactionTooLargeException, so media queries are paged.
- The kernel attaches the caller's UID/PID, letting services enforce runtime permissions on each IPC call.
What Binder is
On Android, each app runs in its own sandboxed process, so calling into a system service means crossing a process boundary. Binder is the IPC subsystem that makes that possible: a `/dev/binder` kernel driver plus a userspace framework that marshals method calls and data (a 'transaction') from one process to another and returns the result, making a remote call look almost like a local one.
Most app developers never touch Binder directly. Instead they call high-level APIs—`ContentResolver`, `PackageManager`, `ActivityManager`, MediaStore—and the framework generates AIDL (Android Interface Definition Language) stubs and proxies that serialize arguments into a `Parcel` and ship them over Binder to the system_server or the relevant service process.
How a cleaner app uses it
When a storage-cleaning app queries the MediaStore to list photos and videos, that call doesn't read the database in the app's own process—it goes through `ContentResolver`, over Binder, to the media provider running in another process, which executes the query and parcels rows back. The same applies to asking `PackageManager` for app sizes or `StorageStatsManager` for cache usage.
Because data is copied through a fixed-size per-process Binder transaction buffer (around 1 MB, shared across in-flight transactions), returning a huge result in one call can throw a `TransactionTooLargeException`. That's why media queries are paged with a `Cursor` and large blobs (thumbnails, file bytes) are passed by `ParcelFileDescriptor` rather than copied inline.
Why it matters for permissions and performance
Binder also carries the caller's identity. The kernel attaches the caller's UID/PID to each transaction, so system services can enforce runtime permissions (for example, checking `READ_MEDIA_IMAGES` before returning media rows). This is how the OS knows whether your app is actually allowed to see the files it's asking about.
Performance-wise, every cross-process call has marshalling and context-switch overhead, so well-behaved apps batch work, page results, and avoid chatty per-item Binder calls in tight loops—relevant when scanning thousands of media items for duplicates.