Options for distributing AIDL interface

Question

What options do developers have for distributing their AIDL interfaces for other projects to use?

So far, I have only been able to get a client project to work by copying the AIDL file from the service project into the client project. That works but it also means that clients (potentially at other companies) need to have my package structure and source in their codebase.

Are there alternative ways of packaging AIDL interfaces that would allow service authors to provide their interfaces in an artifact like a JAR file? I tried making only the generated classes available to a client application but the client wouldn't compile, which leads me to think that the ADK needs access to the AIDL file itself.

Answer 1

What options do developers have for distributing their AIDL interfaces for other projects to use?

Personally, I like receiving my AIDL in the form of a candygram. :-)

So far, I have only been able to get a client project to work by copying the AIDL file from the service project into the client project.

AFAIK, AIDL has to be distributed in source form.

That works but it also means that clients (potentially at other companies) need to have my package structure and source in their codebase.

They only need your AIDL file(s) and knowledge of what Java package to put them in. This is part of your published API, no different than a URL and Web service definition is part of the API of a Web service.

They should not need your source code for anything else. If you elected to use custom Parcelable classes in the AIDL-exposed methods, users of your AIDL would need compiled versions of those classes in a JAR, if not source. In addition, you need to arrange to have Red Bull (or the energy drink of your choice) available on tap for you and your staff, as dealing with version changes of AIDL is annoying enough, let alone version changes of client-side Parcelable classes.

I have no yet experimented with publishing AIDL and code via an AAR-packaged Android library project via Gradle for Android. Once this works (which may or may not be "now"), it would at least allow you to bundle the AIDL and the related compiled Parcelable code into a single artifact, which will help a bit with the versioning issue. OTOH, AAR packages right now can only be consumed by Gradle for Android (and I think the latest version of the Maven plugin), not Eclipse.

Answer 2

Are there alternative ways of packaging AIDL interfaces that would allow service authors to provide their interfaces in an artifact like a JAR file? I tried making only the generated classes available to a client application but the client wouldn't compile, which leads me to think that the ADK needs access to the AIDL file itself.

No. The client must save a copy of the .aidl file under a /src directory with the correct package name. For example, see how Google Play Services requires you to use IInAppBillingService.aidl.

That works but it also means that clients (potentially at other companies) need to have my package structure and source in their codebase.

Yep.