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?

Vietnamese

It would help if you would choose a a correct answer. – Charisecharisma

The Android devs and the Kernel devs had a discussion about binder vs alternatives on the LKML in June 2009 (and possible at other points as well) that makes informative reading on both perspectives, and addressed the details with more specific accuracy than what has been posted here so far. – Asclepiadean

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.

Maryrosemarys

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.

Charisecharisma

Answer 3

Binders are used to to communicate over process boundaries since different processes don't share a common VM context => no more direct access to each others Objects (memory). Both parties within the same process (usually things that are within the same app) means (imho) that you should not use Binders since they slow down / complexify things unnecessary.

Binders are usually not used directly but rather via the "Service" or the "Messenger" classes. While communication with a Service is done via a full api of functions, the communication with a Messenger has to use "Message"s. Messengers a lot simpler to implement.

Apart from using Binders you can use anything that is available from any VM instance like "LocalSocket"s, Files, ContentProviders, Intents, ...

Binders are not ideal for transferring large data streams (like audio/video) since every object has to be converted to (and back from) a Parcel. All the conversion takes time. Much better in that case would be a LocalSocket for example.

Nyctaginaceous

"Both parties within the same process (usually things that are within the same app) means (imho) that you should not use Binders since they slow down / complexify things unnecessary." Intents are actually a Binder abstraction, so unlikely to be faster. – Smelt

@littleScala You're right. Also ContentProvider when used across process boundaries uses Binder as well. My answer is kind of bad :) – Nyctaginaceous

Note that android.os.Binder the object is a distinct thing from the Binder the IPC mechanism (ie, /dev/binder and its usermode wrappings, etc) – Asclepiadean

@ChrisStratton I think I've always assumed the question is about android.os.Binder specifically. But you're right it's not the same as "the mechanism" (cf. newandroidbook.com/files/Andevcon-Binder.pdf p.24 in it's entirety), but neither is /dev/binder or it's userlands wrappings (isn't android.os.Binder actually one of them?) on it's own. – Nyctaginaceous

Answer 4

Binders are used to enable remote procedure calls. You could implement RPC using the synchronization tools you mention but you would also need to write a lot of code to make it come together... with a Binder (normally only used within an Android Service) you have much less code to write; barely more than your actual remote functions.

Afro

Would Binder be appropriate for stream high bandwidth, low latency data between processes (such as audio, or video streams?) – Seriate