Android Artifacts hit Maven Central

It all started now quite a while ago when I got involved with the Maven Android Plugin and found that having to run a bunch of mvn install file commands sucked. I launched a ticket in the Android issue tracker that got rejected by Google even though there was clearly a community demand for the Android jar artifact to hit Maven central. As a next best step I created the Maven Android SDK Deployer and things cruised along okay for a bit. And then out of the blue Robert Manning, from the awesome SQuirrel SQL Client project, contacted me about the status and issues with getting the jars into Maven central if they are built from the open source code drop. And with Robert things really moved.

Initially we were concerned that we would have to verify the correctness of the jar and that might be a huge hazzle. Robert however did not despair and came up with the great approach of using the standard build process for Android. Then repackaging the jars and associated artifacts to a bundle suitable for upload to Maven central via the Sonatype open source sync. All this can be seen in the Android4Maven project. After much back and forth, explanations about the different contents of the jars, scripting and running the builds on Roberts side and testing we succeeded! As of today Maven central hosts the Android jar artifacts including source and javadoc packages for Android 1.5_r3, 1.5_r4, 1.6_r2 and 2.1_r1. As soon as 2.2. hits the git repos it will follow.

In order to use the artifacts in your project you will have to use a dependency like this


with the correct version number for your project.

If you are using some of the unit and instrumentation test classes you will have to also add a dependency to the android-test artifact like that


To see more examples of the usage check out my fork of the Maven Android Plugin Samples, that will probably be pulled upstream soon.

So with this step it got even easier to start a Android project and build it with Maven taking advantages of the power of the Maven Android Plugin and all the other plugins available to Maven users. It also means that other build systems like ivy, gradle and so on can take advantage of the artifacts. In the next while I will update the documentation in the book Maven: The Complete Reference, the wiki pages of the plugin and the Maven Android SDK Deployer. Until then update your project, enjoy and if you find any issues make sure to let us know.

Thanks again for Robert Manning for taking this on and gloriously succeeding and Brian Fox, Hugo Josefson, Juven Xu and Fabrizio Giudici for helping us.

20 comments » Write a comment

  1. It was my pleasure to work with everyone on this, especially Manfred. Also, I’ll be checking the git repo for the 2.2 release (froyo) in the coming weeks and I’ll notify when that is ready. I’ll reiterate that if anyone finds an issue with the artifacts, just let me know and I’ll work to resolve it.



  2. This is really good. thanks for that! Already using it on my RESTProvider lib.

    the scope is wrong though on the example above. It should be:


  3. Carl,

    The scope of provided is correct. Compile scope is wrong because Maven would then try to include the android jar library in your apk. This is however wrong since the respective code is already available on your target platform (e.g. phone or emulator). It is similar to how e.g. the servlet-api should be provided scope on a web app since they app server (or servlet container) is supposed to have that api already available (= provides it for your app).

    In the case of a library compile scope might be correct indicating the need for the library. However users of the library will then again have the dependency and flag it as provided scope…

    Please refer to the book Maven: The Complete Reference for more info about dependency scope (section 3.4.1)

  4. First of all, thanks for going through all these efforts!

    A question though: When depending on android-2.1_r1, compilation of my project breaks, because it cannot find the JSON library from org.json. Did you only include the core sources in these JARs? Because this won’t help a lot if people use code bundled with Android that comes from third parties, such as the JSON parser or Apache Commons HTTP.


  5. Matthias,

    All packages external to android should be a transitive dependency and added in the pom of the artifact. It looks like json is however missing. I will post about it on the maven android developer mailing list and we will discuss more there.

  6. This was now mentioned on the IllegalArgument podcast and some things needed to be clarified so I sent this text below to the mailinglist.

    Hi guys,

    I just listened to your mention of the android jars getting into Maven central and thought I explain a few things.

    1. About the android jar (and maps jar)

    The android jar file as well as the maps jar that comes with the different platforms of the SDK is a stub implementation. All methods in all classes throw exceptions like this (an example)

    protected void setActivity( testActivity) { throw new RuntimeException(“Stub!”); }

    The reason this is the case that all classes pretty much rely on the whole android stack (dalvik vm and all the native libraries and more underneath) to run. The same applies to the unit test classes.

    2. the android jar files in maven central

    Because Google was unwilling to let us just push the original jars from the sdk to maven central we used the open source codebase to rebuild the jars in a maven way and create the bundle that includes sources and javadoc to upload to maven central. Robert Manning (from squirrelsql) did all that work and myself and other helped with testing and other feedback. Brian Fox from Sonatype helped with the deployment.

    3. using in maven

    the important thing to understand is that because of the stubbed nature of the jars you bascially have to run any android code on the emulator or device. Therefore the dependency scope is similar to e.g. the servlet-api in a servlet container and we use provided …

    Hope that cleans things up. More details can be found in the Android chapter of the Maven: The Complete Reference I wrote (and that needs an update to reflect the artifacts on central…check my github branch ๐Ÿ˜‰ )


  7. Another issue:

    I kept getting an error on our build server:
    “ Invalid SDK: Platform/API level 2.1 not available.”

    I was depending on Android like this:

    curiously, it worked on my local machine, so I suspected it’s because on the build server, I did no prior Android artifact installations using maven-android-sdk-deployer.

    Indeed I could verify that after /also/ installing the 2.1 JAR using the SDK installer, the build succeeded.

    It seems like maven-android-plugin is internally still relying on the artifacts deployed by maven-android-sdk-deployer, instead of relying on the artifacts from maven central (which have a different groupid and artifactid).

    Should I raise an issue for this? because currently it’s entirely pointless to use the new dependencies from central.

  8. The error message is not related to the dependency, but to the plugin configuration. You must be specifiying 2.1 in . This error message appears if the sdk installation does not have the required platform (in your case in ANDROID_HOME/platforms/android-7). It worked once you installed the sdk deployer because the install instructions for it say to install all platforms ๐Ÿ˜‰ The deployer itself has nothing to do with the plugin at all. In fact the dependencies dont either. The plugin only works off the configuration and needs the SDK installed including the platform you are using…

    And you conclusion is therefore wrong. I am using the artifacts from central on a daily basis for my builds just fine. The only problem is the json stuff missing you found.. and that is under investigation with Robert.

  9. Hi,

    the most important part of your was swallowed by the blog. Where do I have to put the 2.1_r1? I put it in the version tag, I thought that’s where it goes.

  10. Just to follow up:

    In the plugin configuration, I set the “platform” tag to “2.1”. Is that wrong?

  11. 2.1_r1 goes into the version of the dependency. You can check on maven central what the available version numbers are.

    2.1 or 7 goes into the sdk/platform config of the plugin like you said..

  12. I have a question for you… I have marked a jar file as a dependency but when i do mvn install i notice that it doesn’t get included in the apk file. Any suggestions?

  13. Pingback: Spring Android and Maven (Part 1) | SpringSource Team Blog

  14. Pingback: More Guice for Android and Maven central | simpligility

Leave a Reply

Required fields are marked *.