AIDL vs Messenger

Question

Requirement: Need to expose a service/contract from a different process to other apps. For example: getPhoneRecord(recordId), deletePhoneRecord(phoneId) etc.
Potential solutions: Messenger or AIDL

Based on my analysis, I think AIDL is the only option because Messenger provides a very generic way of sending messages across apps. The Messenger is limited to send(Message) on the client-side and handleMessage(Message msg) on the server. There are other differences too such as multi-threading. But, I care for defining an API contract from a service that other apps/consumers can invoke. Is my understanding correct?

Answer 1

Noting down the points that I have collected when I have to choose a communication mechanism for IPC in our projects. May be helpful for someone.

AIDL or Messenger, AIDL is the best, it gives me freedom to sync and async calls.

Messenger:

• Asynchronous communication.

• A reference to a Handler that can be sent to a remote process via an Intent.

• Complexity is medium.

• Messages sent by the remote process via the messenger are delivered to the local handler.

• When using Messenger, it creates a queue of all the client requests that the Service receives one at a time. All this happens on a single thread.

• In case you want your Service to handle multiple requests simultaneously then you’ll need to make use of AIDL directly and make sure your Service is capable of multi-threading and also ensure thread-safety.

Ref:http://codetheory.in/android-interprocess-communication-ipc-messenger-remote-bound-services/ https://www.slideshare.net/yoni1984/ipc-aidl-sexy-not-a-curse

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.

Answer 2

Per Android documentation:

Most applications should not use AIDL to create a bound service, because it may require multithreading capabilities and can result in a more complicated implementation.

I just want to make sure that I am certain that AIDL is my best friend out there. So, I came up with the following summary of implementing background services in Android:

Broadly, Services in Android can be started or bound

Started Services Given that a started service performs a single operation and does not return a result to the caller, so it can't met my specific requirements (expose a service/contract from a different process to other apps. For example: getPhoneRecord(recordId), deletePhoneRecord(phoneId) etc.)

Bound Services There are three different flavors

1. Extend the Binder class- used only for private services, runs within the app. Can’t cross process boundary. SO I can't use this either.
2. Use a Messenger- provides a very generic way of sending messages across apps. The Messenger is limited to send(Message) on the client-side and handleMessage(Message msg) on the server.
3. Use AIDL- the winner!

Will appreciate if anyone can weigh in on my decision.

Answer 3

Yes, your understanding is correct. In either case you have to clearly define your API. If using Messenger, it is just async, custom messages so if you need your service to send data back you would need some type of similar mechanism on the client side as well. Using AIDL and binders is more in-line with what you describe you'd like to do.