Category: Blog, Android, Java, Kotlin

How to Distribute Android Libraries

Even the best library is barely usable if potential users cannot get it easily. That’s why every library should be distributed. In this article, I show you how and where you can publish your libraries in the most efficient way.

How to distribute Android libraries

Background

40330572

Usually we declare repositories for dependencies in buildscripts like this:

We can specify explicit URLs but for most of the popular repos, Gradle has dedicated methods. Ideally (for users), a library should be available on Maven Central or JCenter. They usually have those repositories already defined. Each repository increases dependency resolution time and of course requires a little bit more of buildscript code.

Let’s check a few ways how to make your library available.

Maven Central

KgcUeAo

Maven Central repo is usually the best one from user’s perspective. The vast majority of popular libraries are hosted there so usually it is already declared in buildscript, there is no need to add any repository URL. Moreover, Maven Central have many mirror servers making it highly accessible.

Unfortunately, Maven Central is not very affordable from the library author’s perspective. The preparation and publishing process is quite complicated.

Firstly, in order to publish a library there, you need to have an account on OSS Sonatype. If you don’t have one, you need to perform the following steps:

  1. Create account on OSS JIRA
  2. Choose your coordinates (group id like io.reactivex)
  3. Create JIRA ticket

And wait for manual approval from Sonatype maintainers. Usually it takes from 1 to 2 business days. Fortunately, this is a one time process. After that, you will be able to publish updates for the requested artifact and others under the same group (or any of its subgroups) without need to wait.

Please note: you have to be an owner or designated maintainer of domain used in coordinates. Read more in producer guide how to verify ownership. In case of source code hosted on GitHub this rule is applicable to username or organization and is verified automatically.

Your artifacts (no matter if it is the first one or an update) need to meet the requirements. Especially they need to be open source and have valid PGP signatures. Moreover, you need to fill-in required metadata and setup deployment in buildscript. Look at official documentation for Gradle-based projects for more information. In case of Android libraries there is also a dedicated 3rd party plugin.

Actual deployment is also not straightforward. There are few steps need to be performed:

  • Upload artifacts to staging repository
  • Close staging repository
  • Release staging repository

There are 3rd party tools automating this process like Shipkit. However, (at the time of writing) it is not compatible with Android library projects.

JCenter

baby meme
JCenter is a kind of superset of Maven Central. Everything available on the latter is also available on the former but some artifacts may be available only on JCenter. Deployment to JCenter is a little bit easier:

  1. Sign up to Bintray
  2. Set up Bintray Gradle plugin
  3. Request include the package in JCenter

Once your request is approved you can update that package by just invoking Gradle task without additional reviews. You can also sync it to Maven Central. However, JCenter sometimes have availability issues which may be annoying to users.

JitPack

home

Using JitPack is as easy as a pie for library authors. Usually you don’t need to do anything besides pushing source code to remote repo on GitHub, Bitbucket, GitLab or Gitee. Adding appropriate tags will help library users since tags are directly mapped to artifact versions.

Official guideline for Android libraries states that android-maven Gradle plugin is required. However, in practice it is not mandatory as long as AAR files can be produced in a compatible way JitPack will handle it properly. See FoQA build log as a proof.

Note that compilation is done on JitPack servers, so buildscript must not use any non-portable configuration (like custom external tools). Additionally, users have to add JitPack repository to their buildscripts:

Note the repositories order. It matters when they contain artifact having the same coordinates but different content. Here you can read an article about that confusing dependency.

Wrap up

If high availability and ease for users are essential to you, use Maven Central. Either directly or via sync from JCenter.

If your priority is to make your artifacts available quickly and you don’t want to spend much time on configuration, use JitPack – especially if they are used only by your other projects. You can always set up deployment to Maven Central later – for example after your library becomes more popular.

Good luck with your libraries’ distribution!

About the author

Karol Wrótniak

Karol Wrótniak

Mobile Developer

Flutter & Android Developer with 12 years of experience. A warhorse with impressive experience and skills in native and Flutter app development. Karol is probably the most active contributor to open source libraries you've ever met. He develops Gradle plugins and Bitrise steps, and he is engaged in many projects, in particular those related to testing.

Karol has been engaged as a speaker in many events and meetups like DevFest, 4Developers Wrocław, JDD Conference, Linux Academy, and more. He is an active member of Google Developers Group Wrocław, Flutter Wrocław, and Bitrise User Group.