Advantages of using Binder for IPC in Android

Question

What is the advantage of using Binder for IPC over (Semaphores , Message Queue, PIPES) in Android stack?

Answer 1

Old question (and likely unmonitored by the poster), but worth answering:

A) All filesystem-based or filesystem-representable IPC mechanisms (notably pipes), can't be used because of a lack of a world-writable directory, where all processes can mkfifo/create the filesystem/socket representation of their IPC port (/dev/socket notwithstanding, which is used for system processes, e.g. rile, zygote, and their ilk).

B) None of the suggested mechanisms have the capability of "service location" which is required for Android. In UNIX, there's an RPC portmapper, and Android needs similar functionality. Enter: The ServiceManager, which can use binder to register as a context manager, to register/lookup service handles on the fly

C) There is an extensive need for serialization - be it intents, or other messages. Binder provides the parcel abstraction, which can be used for data marshaling by the Parcel.java.

D) SysV has other issues than Mr. Lambada's answer which are more paramount, notably race conditions, and lack of authorization.

E) Message queues and pipes can't pass descriptors. UNIX Domain sockets may, but can't be used because of (A) (again, unless you're root/system, like zygote, rild, installd..)

F) Binder is really lightweight, and has built-in authorization mechanisms. It also has nifty features like waking up the recipient process, as well as memory sharing, which the other mechanisms simply don't have. (and remember, no mmap(2), because of the file problem in (A) for named mappings).

and - let's not forget

G) Binder was started at Palm (ah, nostalgia) (q.v. OpenBinder). Ex-palmers got to Android, and brought their code in with them.

Answer 2

From the ndk's docs/system/libc/SYSV-IPC.html file:

Android does not support System V IPCs, i.e. the facilities provided by the following standard Posix headers:

<sys/sem.h>   /* SysV semaphores */
<sys/shm.h>   /* SysV shared memory segments */
<sys/msg.h>   /* SysV message queues */
<sys/ipc.h>   /* General IPC definitions */

The reason for this is due to the fact that, by design, they lead to global kernel resource leakage.

For example, there is no way to automatically release a SysV semaphore allocated in the kernel when:

• a buggy or malicious process exits
• a non-buggy and non-malicious process crashes or is explicitly killed.

Killing processes automatically to make room for new ones is an important part of Android's application lifecycle implementation. This means that, even assuming only non-buggy and non-malicious code, it is very likely that over time, the kernel global tables used to implement SysV IPCs will fill up.

At that point, strange failures are likely to occur and prevent programs that use them to run properly until the next reboot of the system.