Broadcast Receivers for Android

Question

What are the pros and cons of using auxiliary and broadcast receivers to send messages between applications (for background and foreground processing)? I use receivers that are good because of the subscription model with intent filters and ease of use / extensibility. Are there any flaws in using this approach to vs AIDL?

thanks Ben

Answer 1

BroadcastReceiver

• This is asynchronous communication.
• Low complexity is the easiest way to communicate between processes.
• One-to-all communication — Broadcasting simultaneously transmits a message to all recipients.
• Android OS based on the intent of communication between application components .
• BroadcastReceiver.onReceive always starts in the main thread (UI thread)

• When sending data through intent, you must be careful to limit the data size to a few kilobytes. Sending too much data may cause the system to raise a TransactionTooLargeException. https://developer.android.com/guide/components/activities/parcelables-and-bundles

  Allegations that Intents can transfer data up to 1 MB in size are clearly false, 500 KB are more accurate. https://www.neotechsoftware.com/blog/android-intent-size-limit "

• Security. The broadcast is transmitted through the Android OS, which may pose a security risk. Other applications may listen to broadcasts. Any confidential data should not be broadcast.

---

Aidl

• This is a synchronous and asynchronous interprocess communication. By default, AIDL communication is synchronous. To make the AIDL link asynchronous, use the oneway keyword.

• Complexity is high - the AIDL interface sends simultaneous requests to a service that must handle multithreading.

• Individual communication

• Using the Android OS Binder Base Platform

• Writing thread safe code is required.

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

• Security: AIDL allows developers to provide their interfaces to other applications. Both the client and the service agree to communicate with each other .

Answer 2

I think that one rollback can be battery life, since when listening to the receiver, voltage constantly appears at the battery level. BroadCastReceivers may have security holes if you do not allow allocation permission when broadcasting, unless your broadcast is local, of course you can use the LocalBroadcastManager.

AIDL seems to me safer, but harder to disengage for general use in a group. I like AIDL files when I have many different API calls that I want to make in another process. It is like a remote control. With Broadcastreciever, it can be harder to directly call custom methods to do the job.

Answer 3

Aidl

General use:

• Allows an application to act as a server that serves the requests of one or more application clients.

Minuses:

• Regarding broadcasting , its implementation is more complex.
• Requires multithreading processing, as the service receives requests simultaneously

broadcasting

General use:

• Allows an application to send broadcast messages to one or more applications (listeners) that something interesting has happened in the application.

Finally:

Since this is not the case when one size fits all, each approach has its own applications, where it works better.

• For example, it is more efficient to use AIDL in such cases:

  - Requires a server serving many clients simultaneously

  - The client not only sends a request to the server, but also uses the returned response.

• On the other hand, it is more efficient to use broadcasting in such cases as:

  - The subject must notify its observers of an interesting event (it happens infrequently). [as opposed to the survey design].

  - One application must notify the other application of something and does not use the returned response.

Both approaches can be protected in the same way, with Android permissions. Which allows only applications signed with the same key to exchange information.