AIDL use case!

AIDL does nothing but lets the system to generate the boilerplate code that hides the binder IPC details, so that you can invoke the remote service API as a local method call. Using AIDL is necessary only if you allow clients from different applications to access your service for IPC and want to handle multithreading in your service. So,If you don’t need IPC (i.e., your client and server stay in the same process), you don’t need AIDL;

If you want to write the boilerplate code yourself for IPC, you don’t need AIDL;

If your service is not complicated enough (i.e., does not require concurrent multithreaded accesses), you can use system provided Messenger API for IPC. You don’t need your own AIDL, because the Messenger API hides the AIDL usage;

To extend the case 3, if you can use any existing lib or existing API to access a service in another process, you don’t need your own AIDL. For example, you can access ActivityManagerService with existing system API, and all the AIDL stuff for IActivityManager is hidden by the system API.

Use AIDL or Messenger Queue?

AIDL is for the purpose when you’ve to go application level communication for data and control sharing, a scenario depicting it can be: An app requires list of all contacts from Contacts app (content part lies here) plus it also wants to show the call’s duration and you can also disconnect it from that app (control part lies here).

In Messenger Queues you’re more IN the application and working on threads and processes to manage the queue having messages so no Outside services interference here.

Messenger is needed if you want to bind a remote service (e.g. running in another process).