Android broadcast receivers vs aidl

Question

What are the pros and cons of using aidl vs broadcast receivers for sending messages between apps (for both background and foreground handling)? I've been using receivers which is nice due to the subscription model with intent filters, and the ease of use / extensibility. Are there drawbacks to using this approach to vs AIDL?

Thx Ben

School

I too have the same question actually. – Fraze

we decided to go with Broadcast receivers, and have not regretted the decision. For dealing with events, this is just simply the way to go, perfect for pub/sub. We also make use of Content Providers as well for querying data... – School

Answer 1

BroadcastReceiver

• It is an Asynchronous communication.
• Complexity is low- It is the easiest way to communicate between processes.
• One to All communication- A broadcast is transferring a message to all recipients simultaneously.
• Android OS intent based communication between application components.
• BroadcastReceiver.onReceive always run in the main thread(UI thread)

• When sending data via an intent, you should be careful to limit the data size to a few KB. Sending too much data can cause the system to throw a TransactionTooLargeException exception. https://developer.android.com/guide/components/activities/parcelables-and-bundles

  The statements that Intents could transfer up to 1Mb worth of data are definitely wrong, 500Kb is more accurate. https://www.neotechsoftware.com/blog/android-intent-size-limit"

• Security: A broadcast is transmitted across the Android OS and that could introduce a security threat.Other apps can listen to broadcasts. Any sensitive data should not be broadcasted.

---

AIDL

• It is Synchronous and Asynchronous inter process communication. By default,the AIDL communication is synchronous. In order to make AIDL communication asynchronous, use “oneway” keyword.

• Complexity is high - AIDL interface sends simultaneous requests to the service, which must handle multi-threading.

• One to One communication

• Using the underlying Android OS Binder framework

• Requires writing thread-safe code.

• The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process. https://developer.android.com/reference/android/os/TransactionTooLargeException.html"

• Security: AIDL is allows developers to expose their interfaces to other application. Both the client and service agree upon in order to communicate with each other.

Centiliter

Answer 2

I think one draw back might be the battery life as having a receiver listening constantly puts strain on battery level. BroadCastReceivers can have security holes if you dont emphasis permissions when broadcasting also unless your broadcasting locally then you can use LocalBroadcastManager of course.

AIDL to me seems more secure but harder to abstract for general use in a group. I like AIDL files when i have many different API calls i want to make in another process. Its like a remote control. with a Broadcastreciever might be harder to directly call custom methods to do work.

Bronchiole

Answer 3

AIDL

Common uses:

• Allows an app to act as a server which serves the requests of one or more clients –apps.

Cons:

• Relative to the Broadcasting, its implementation is more complex.
• Requires handling of multi-threading as the service receives requests simultaneously

Broadcasting

Common uses:

• Allows an app to send broadcasts to one or more apps (listeners) about something interesting occurred in the app.

In conclusion:

As it's not the case that one size fits all, each approach has its uses where it performs better.

• For instance its more efficient to use AIDL in cases like:

  – A server serving many clients simultaneously is required

  – A client will not only send a request to a server but also consumes the returned response.

• On the other hand its more efficient to use Broadcasting in cases like:

  – A subject needs to notify his observers of an interesting event (occurs infrequently). [unlike the polling pattern].

  – One app needs to notify another app of something and doesn't consume the returned response.

Both approaches can be secured using the same way, custom android permissions. Which allows only the apps signed with the same key to share in the communication.

Microgroove