0

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.

spaaarky21
  • 6,524
  • 7
  • 52
  • 65

2 Answers2

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.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Unfortunately, I believe you are right that AIDL has to be distributed as AIDL and placed in the right place by the client's author. Thanks for confirming. I was hoping for something more elegant but that's also how Google suggests doing it with their AIDL services. http://developer.android.com/google/play/billing/billing_integrate.html – spaaarky21 Jan 07 '14 at 20:06
  • I wasn't aware of the new AAR archive format. It looks promising but from the information at http://tools.android.com/tech-docs/new-build-system/aar-format, it seems like it may be limited to compiled source (i.e., class files in a JAR) and resources/assets. There's no mention of source, even if AIDL isn't "source" in the typical Foo.java sense of the word. The more I deal with it, the more I get the feeling that AIDL is one of Android's less well-considered areas. – spaaarky21 Jan 07 '14 at 20:10
  • @spaaarky21: Yeah, again, I haven't tried it. Gradle for Android certainly supports AIDL, but I do not know if they have extended that to AARs just yet. They should, for scenarios like yours. – CommonsWare Jan 07 '14 at 20:14
0

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.

Brian Attwell
  • 9,239
  • 2
  • 31
  • 26