Android AIDL
AIDL is functionality in Android to communicate with other processes and share the data. Though there are many IPC mechanisms Aidl is often chosen because:
Remote procedure calls (RPC) using Android’s inter-process communications largely replace the use of the Java Native Interface (JNI) in Android. In almost all cases, a remote procedure call is efficient enough to make it a superior alternative to loading a library—especially one that dynamically allocates a significant amount of memory—into the Java virtual machine’s address space. And if a process exposing an RPC interface fails, it is less likely to bring down the Android UI with it.
Android inter-process communication behaves a lot like JNI: the caller’s thread is blocked until the result is returned. Marshalling data across the IPC boundary is about the same amount of work as data conversions in JNI. But Binder-based remote procedure calls have a significant advantage over JNI: if non-Java code crashes or runs out of memory, the caller of a remote procedure call gets an error that must be handled, but the Java application does not crash. Remote procedure calls are a more robust way to call “external” libraries and subject the Java application to fewer risks in the form of clashing memory management strategies and other differences between Java applications and libraries implemented in languages other than Java.
Now that we know the advantage let me explain how it works:
1.Declare the functions which you want to make available to different processes in .aidl file
2. Define the functions in a Service file which may/may not use the function's capabilities.
3. Call the functions from remote/local process by sharing the aidl file in those processes.
If you are using ADT pluggin then aidl file is autocompiled when the project is compiled. Result is .java file.
When you share this aidl file in both projects/processes , .java file will be created. The caller needs this java file just to marshall the data to be sent and unmarshall the data received.
The important parts in generated .java file are:
1.The Stub Class is primary class you need to define the aidl declared functions.
2.There is asInterface class which will return the instance of the implemented functions.
3.Proxy Class has definitions of the data and functions you implemented.. This is almost similar to JNI file.
4.onTransact method is used to marshall and unmarshall the data shared..
Now when you share aidl file with caller and called process/activity and when call to the "shared function" is raised:
1.First The Caller program will check if it can obtain the binder object from asInterface.
2.Then it checks if the binder object was local implementation, if so returns then, no IPC call is needed so it returns the local object.
3. Otherwise it calls Proxy class and gets its own proper definition of the functions implemented.
4. onTransact(caller) method then marshalls the data to be sent , forms parcel objects and sends it to called process where actual definition lies.
5. onTransact method(called) receives the parcel object, unflattens it... Calls the functions ... and Returns the result to caller by forming a parcel again .
6.onTransact method (caller) unmarshalls it and returns the data , which can be accessed from binder object obtained from asInterface.
This is just basic flow and my understanding of Aidl . I request you to go through "OReilly Android Application Development May 2009" for detailed explanation.
The Download link of the my demo file is :
https://sourceforge.net/projects/androidaidldemo
Remote procedure calls (RPC) using Android’s inter-process communications largely replace the use of the Java Native Interface (JNI) in Android. In almost all cases, a remote procedure call is efficient enough to make it a superior alternative to loading a library—especially one that dynamically allocates a significant amount of memory—into the Java virtual machine’s address space. And if a process exposing an RPC interface fails, it is less likely to bring down the Android UI with it.
Android inter-process communication behaves a lot like JNI: the caller’s thread is blocked until the result is returned. Marshalling data across the IPC boundary is about the same amount of work as data conversions in JNI. But Binder-based remote procedure calls have a significant advantage over JNI: if non-Java code crashes or runs out of memory, the caller of a remote procedure call gets an error that must be handled, but the Java application does not crash. Remote procedure calls are a more robust way to call “external” libraries and subject the Java application to fewer risks in the form of clashing memory management strategies and other differences between Java applications and libraries implemented in languages other than Java.
Now that we know the advantage let me explain how it works:
1.Declare the functions which you want to make available to different processes in .aidl file
2. Define the functions in a Service file which may/may not use the function's capabilities.
3. Call the functions from remote/local process by sharing the aidl file in those processes.
If you are using ADT pluggin then aidl file is autocompiled when the project is compiled. Result is .java file.
When you share this aidl file in both projects/processes , .java file will be created. The caller needs this java file just to marshall the data to be sent and unmarshall the data received.
The important parts in generated .java file are:
1.The Stub Class is primary class you need to define the aidl declared functions.
2.There is asInterface class which will return the instance of the implemented functions.
3.Proxy Class has definitions of the data and functions you implemented.. This is almost similar to JNI file.
4.onTransact method is used to marshall and unmarshall the data shared..
Now when you share aidl file with caller and called process/activity and when call to the "shared function" is raised:
1.First The Caller program will check if it can obtain the binder object from asInterface.
2.Then it checks if the binder object was local implementation, if so returns then, no IPC call is needed so it returns the local object.
3. Otherwise it calls Proxy class and gets its own proper definition of the functions implemented.
4. onTransact(caller) method then marshalls the data to be sent , forms parcel objects and sends it to called process where actual definition lies.
5. onTransact method(called) receives the parcel object, unflattens it... Calls the functions ... and Returns the result to caller by forming a parcel again .
6.onTransact method (caller) unmarshalls it and returns the data , which can be accessed from binder object obtained from asInterface.
This is just basic flow and my understanding of Aidl . I request you to go through "OReilly Android Application Development May 2009" for detailed explanation.
The Download link of the my demo file is :
https://sourceforge.net/projects/androidaidldemo
Comments
Post a Comment
Please post comments here:-)