What’s Android Interface Definition Language (AIDL) in Android?
Last Updated :
11 Oct, 2022
The Android Interface Definition Language (AIDL) is analogous to other IDLs you would possibly have worked with. It allows you to define the programming interface that both the client and repair agree upon so as to speak with one another using interprocess communication (IPC). Traditionally the Android way a process cannot access the memory of some other process. So in order to be able to communicate they decompose their objects into primitives that the Operating System can understand well, and marshall the objects across that boundary for you. The code to try to do that marshaling is tedious to write down, so Android handles it for you with AIDL.
Note: Using AIDL is important as long as you permit clients from different applications to access your service for IPC and need to handle multithreading in your service.
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.
Defining an AIDL Interface
You must define your AIDL interface in a .aidl file using the Java programming language syntax, then reserve it within the ASCII text file (in the src/ directory) of both the appliance hosting the service and the other application that binds to the service. To create a .aidl file use this link!
Sounds confusing?
Well, here’s an example:
Process A needs info of Call status to work out whether it must change Call Type (for instance changing voice to video). you’ll get call status from certain listeners but to vary Call type from Audio to Video, Process A needs a hook to vary. This “Hook” or way of adjusting calls is usually a part of “> a part of Telephony Classes which are part of Telephony Process. So as to get such a piece of information from the Telephony process, One may write a telephony service (which runs as a neighborhood of android telephony process), which can allow you to question or change call type. Since Process A(Client) here is using this remote Service which communicates with the Telephony process to change call type, it must have an interface to speak to the service. Since Telephony service is that the provider and Process A (client) is that the user, they both got to agree on an interface (protocol) they will understand and cling to. Such an interface is AIDL, which allows you to speak (via a foreign service) to the Telephony process and obtain some work done.
Simply put in laymen’s terms, AIDL is an “agreement” the Client gets, which tells it about the way to ask for service. The service itself will have a replica of that agreement(since it published for its clients). Service will then implement details on how it handles once an invitation arrives or say when someone is lecturing it
So process A requests to vary call via Service, Service gets the request, it talks to telephony process(since it’s a part of it) and changes call to video.
An important point to notice is, AIDL is merely necessary for a multithreading environment. you’ll do away with Binders if you do not get to affect multithreaded arch. Example: Process A needs info of Call status to work out whether it must change Call Type (for example Audio to Video Call or Vice-versa). you’ll get call status from certain listeners but to vary Call type from Audio to Video, Process A needs a hook to vary. This “Hook” or way of adjusting calls is usually a part of “> a part of Telephony Classes which are part of Telephony Process. So as to get such information from the Telephony process, One may write a telephony service (which runs as a neighborhood of the android telephony process), which can allow you to question or change call type. Since Process A(Client) here is using this remote Service which communicates with the Telephony process to change call type, it must have an interface to speak to the service. Since Telephony service is that the provider and Process A (client) is that the user, they both got to agree on an interface (protocol) they will understand and cling to. Such an interface is AIDL, which allows you to speak (via a foreign service) to the Telephony process and obtain some work done.
Simply put in laymen’s terms, AIDL is an “agreement” the Client gets, which tells it about the way to ask for service. The service itself will have a replica of that agreement(since it published for its clients). Service will then implement details on how it handles once an invitation arrives or say when someone is lecturing it
So process A requests to vary call via Service, Service gets the request, it talks to telephony process(since it’s a part of it) and changes call to video.
An important point to notice is, AIDL is merely necessary for a multithreading environment. you’ll do away with Binders if you do not get to affect multithreaded arch.
Here’s a code snippet to guide you in action:
Java
interface GeeksforGeeks {
int add(int x,int y);
int sub(int x,int y);
}
|
The AIDL Service for the above code is:
Java
public class AidlServiceGfG extends Service {
private static final String TAG = "AIDLServiceLogs";
private static final String className = " AidlService";
public AidlService() {
Log.i(TAG, className+" Constructor");
}
@Override
public IBinder onBind(Intent intent) {
Log.i(TAG, className+" onBind");
return iCalculator.asBinder();
}
@Override
public void onCreate() {
super.onCreate();
Log.i(TAG, className+" onCreate");
}
@Override
public void onDestroy() {
super.onDestroy();
Log.i(TAG, className+" onDestroy");
}
ICalculator.Stub iCalculator = new ICalculator.Stub() {
@Override
public int add(int x, int y) throws RemoteException {
Log.i(TAG, className+" add Thread Name: "+Thread.currentThread().getName());
int z = x+y;
return z;
}
@Override
public int sub(int x, int y) throws RemoteException {
Log.i(TAG, className+" add Thread Name: "+Thread.currentThread().getName());
int z = x-y;
return z;
}
};
}
|
And here’s the service connection:
Java
ServiceConnection serviceConnection = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
Log.i(TAG, className + " onServiceConnected");
iCalculator = ICalculator.Stub.asInterface(service);
}
@Override
public void onServiceDisconnected(ComponentName name) {
unbindService(serviceConnection);
}
};
|
Conclusion
AIDL uses the binder kernel driver to form calls. once you make a call, a way identifier and every one of the objects are packed onto a buffer and copied to a foreign process where a binder thread waits to read the info. When calls are made within the same process and therefore the same backend, no proxy objects exist, then calls are direct with no packing or unpacking.