What is AIDL in Android?
Android Interface Definition Language
AIDL stands for “Android Interface Definition Language.” It’s a language used in Android for defining the interface between a client and a service that runs in a separate process. AIDL is primarily used for interprocess communication (IPC) in Android, allowing different components of an app to communicate with one another when they are running in separate processes. This is often used in scenarios like creating bound services or remote service interactions. AIDL files define the methods that can be called on a remote service and the data types that can be passed between the client and the service.
The Android Interface Definition Language (AIDL) is similar to other IDLs: it lets you define the programming interface that both the client and service agree upon in order to communicate with each other using interprocess communication (IPC).
On Android, one process can’t normally access the memory of another process. To talk, they need to decompose their objects into primitives that the operating system can understand and marshall the objects across that boundary for you. The code to do that marshalling is tedious to write, so Android handles it for you with AIDL.
Note: AIDL is necessary only if you let clients from different applications access your service for IPC and you want to handle multithreading in your service. If you don’t need to perform concurrent IPC across different applications, create your interface by implementing a Binder. If you want to perform IPC but don’t need to handle multithreading, implement your interface using a Messenger. Regardless, be sure that you understand bound services before implementing an AIDL.
How it works
AIDL uses the binder kernel driver to make calls. When you make a call, a method identifier and all of the objects are packed onto a buffer and copied to a remote process where a binder thread waits to read the data. Once a binder thread receives data for a transaction, the thread looks up a native stub object in the local process, and this class unpacks the data and makes a call on a local interface object. This local interface object is the one a server process creates and registers. When calls are made in the same process and the same backend, no proxy objects exist, and so calls are direct without any packing or unpacking.
But Before you go off start designing your own AIDL, do note that calls to an AIDL are straightaway right function calls! So you shouldn’t assume about the thread during the execution of whom the decision occurs. What happens is different counting on whether the decision is from a thread within the local process or a foreign process.
Specifically
- Calls made up of the local process are executed within the same thread that’s making the decision. If this call is from your main UI thread often then that will continue to exec within the AIDL interface, however in case if it is another one (thread) then that one will execute yours within the service!
- Calls from a foreign process are dispatched from a thread pool the platform maintains inside your own process. you want to be prepared for incoming calls from unknown threads, with multiple calls happening at an equivalent time.
- The oneway keyword decides how the behavior of the remote call would be, When used, a foreign call doesn’t block; it simply sends the transaction data and immediately returns. The implementation of the interface eventually receives this as a daily call from the Binder thread pool as a traditional remote call. If oneway is employed with an area call, there’s no impact and therefore the call remains synchronous.
