Publishing your Android Library

Libraries are an integral part of any ecosystem. Android ecosystem is no different, libraries constitute a significant portion of the application. This article will go through the steps for publishing an android library.

To publish an android library following are the required steps:

• Prepare the library for release.
• Configure publication variants.
• Upload library.

Prepare the library for release

During the preparation step, you configure settings such as the library name, the technical requirements to run or embed the library, and metadata that help the Android Gradle plugin (AGP) consume libraries.

Choose a namespace

Android libraries need to declare a namespace so that they can generate a unique R class when their resources are compiled. This namespace should closely match the library’s root class package to avoid confusion when users import regular classes from the library as well as its R class.

Starting with AGP 7.0, you can set the namespace in the module’s build.gradle file as shown in the following code example:

Choose a minSdkVersion value

Choosing a minSdkVersion for your library is an important aspect of publishing your library. The minSdkVersion should reflect the minimum version of Android that your code can support.

When choosing the minimum SDK version we need to balance between wider reach and feature support. Like, a higher SDK version would prevent the applications from using it. While a lower SDK version allows for wider distribution. Refer to the official documentation for more considerations.

Setup AAR metadata

An Android library is packaged in the form of an Android Archive (AAR) file. AAR metadata consists of properties that help AGP consume libraries. If your library is consumed by an incompatible configuration, and AAR metadata is set up, users are presented with an error message to help them resolve the issue.

AAR metadata does not contain properties that are important at runtime and therefore are not typically found in compiled Android applications.

The metadata consists of data like minCompileSdk , testFixtures , etc.

Refer to the official documentation for more details.

Note: Some of this metadata or steps mentioned above are optional but it is best to specify them.

Configure publication variants

Configuring publication variants allows us to publish different build variants, each with its own attributes. Publishing multiple build variants of your library allows your user to choose the appropriate features for their needs. Publication variants allow you to create a more customized experience for your users.

In order to publish variants of your library, you must use Gradle Module Metadata (GMM) GMM is used to describe your publication and maintain variant-aware dependency management. It is published with your library by default.

Create a software component with a single publication variant

The below snippet configures a software component with a single publication variant created from the release build variant, and adds the source JAR as a secondary artifact:

For most cases single publishing variant is enough. For the sake of simplicity will stick to single variant in this article. Refer to the official documentation to know more about multiple publication variants.

Upload library

This involves choosing a distribution mechanism and creating the actual publication. A library can be published or distributed via a repository or as an AAR(shared via any online hosting service).

It is preferred to distribute libraries via a repository since pulls the required additional dependencies, resolves conflicts, etc. Refer to the official documentation for a comparison between repository and direct aar distribution.

Publishing to a Repository

Repositories could be of multiple types:

• Free and public repositories that allow anyone to upload and download libraries, for example, Maven Central.
• Private repositories that control distribution via credentials
• Local repositories that are part of your local system or organization’s local network.

We will go through the steps for publishing the library to maven central.

This article does not cover the steps to set up an account for publishing to maven central. Refer to the official documentation to set up a maven central account.

Configure Publishing

Adding publishing metadata

Create a gradle.properties file in the library module and add the below metadata(This data can be added in the root level gradle.properties file for a project if it has only 1 library module to be published. For projects with multiple library modules, the metadata should be added to the module level gradle.properties).

Add the following metadata in the gradle.properties at the root level of your project(This data can be added to the module level gradle.properties as well. Generally, this metadata is consistent across the organization hence best to have it in the root for multi-module projects).

Add Publishing Plugin

• Configure maven central credentials and signing config in the Gradle home of your system or CI server. It is recommended to configure credentials in the Gradle home to avoid accidental pushes of the credentials to the version control.
  To configure credentials in the Gradle home create a gradle.properties file and add the following configuration.

• Create a folder named publishing-plugin in the root of the project
• Create a build.gradle.kts file and add the below content

• Create a file in the following path /src/main/kotlin/mvn-publish.gradle.kts and add the below script

• Add plugin to the project by including the following in your settings.gradle(.kts) file.

includeBuild("publishing-plugin")

• Do a gradle sync and build the project using the assemble command.
• Add the puglin to the library module as shown below

• Do a gradle sync and build the project using the assemble command.

You are now ready to publish your plugin to maven central.

Publish to Maven Central

To publish to maven central use the following command(s)

Once the library is uploaded, login to the OSSRH web UI to promote and close the repository.

If the version name ends with -SNAPSHOT the script takes care of uploading the build to the snapshot repository of maven central.

Refer to the fcm-client-lib github repository for a complete sample.