Should I use AIDL or not?

Question

What are the advantages of using AIDL while we can use java interfaces to help client applications call the bound service?

For example, For ITestService we should create an AIDL as follows:

// ITestService.aidl
package com.varanegar.vaslibrary.service;

// Declare any non-default types here with import statements

interface ITestService {
    /**
     * Demonstrates some basic types that you can use as parameters
     * and return values in AIDL.
     */
    void basicTypes(int anInt, long aLong, boolean aBoolean, float aFloat,
        double aDouble, String aString);
    int test();
}

Then we should implement the generated Stub class:

public class TestService extends Service {
    public class TestImpl extends ITestService.Stub{

        @Override
        public void basicTypes(int anInt, long aLong, boolean aBoolean, 
           float aFloat, double aDouble, String aString) throws RemoteException {

        }

        @Override
        public int test() throws RemoteException {
            return 0;
        }
    }
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return new TestImpl();
    }
}

Though, I belive We can easily create a java Interface like this:

interface ITestService {
    int test();
}

and then create our service that implements that interface:

public class TestService extends Service implements ITestService {
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }

    @Override
    public int test() {
        return 0;
    }
}

According to Wikipedia:

AIDL: Java-based, for Android; supports local and remote procedure calls, can be accessed from native applications by calling through Java Native Interface (JNI)

Is there any other compelling reason to use AIDL instead of normal java services?

It seems to me that I can use bound and started services without any AIDL. Because this is possible to write java interfaces in an android library as a contract between the server and all client applications.

I do not intend to create a native application. So if AIDL is used to expose Java services to a native application, is it right to use that in my case? Am I right? Please correct me if I misunderestood AIDL.

Thanks in advance

Loisloise

If i get it properly , you are correct but the difference here is that you are not exposing a library but a background service , thus you need AIDL , so that Android internally can expose the definition to all applications require it. Did you try exposing the service without AIDL , and it worked? – Legault

"and then create our service that implements that interface" -- you can do that, but it will be useless. The client of the service has no access to the Service object in your scenario. "According to Wikipedia" -- Wikipedia is incorrect, insofar as AIDL has little to do with JNI. "instead of normal java services?" -- what is a "normal java service"? "It seems to me that I can use bound and started services without any AIDL." -- within one process, yes, but not across processes. – Taynatayra

By the way, another way for process1 service to communicate with process2 activity is via cave man file. – Grisby

Answer 1

From the documentation:

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. If you do not need to perform concurrent IPC across different applications, you should create your interface by implementing a Binder or, if you want to perform IPC, but do not need to handle multithreading, implement your interface using a Messenger. Regardless, be sure that you understand Bound Services before implementing an AIDL.

Dody

Answer 2

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. So,

1. If you don't need IPC (i.e., your client and server stay in the same process), you don't need AIDL;

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

3. 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;

4. 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.

Ruttger

From what I know. A function in process 1 has NO access to memory in process 2. So good luck @Xiao Feng – Grisby

@JaveneCPPMcGowan "Access" here does not mean to access the memory of another process, but specifically "to use the service" provided by another process. I believe the meaning is clear in the context of talking about AIDL, especially when an example has been given. – Ruttger

Answer 3

By the way, another way for process1 service to communicate with process2 activity is via cave man files. Service writes to one file. Activity reads file and responds to service on another file. Call a file read loop on the file which should block until bytes are written to it. Doing this on seperate thread.

Grisby