Building and Publishing Android Libraries to Maven Central

An Android library module applies the com.android.library plugin instead of com.android.application. The two plugins share almost the entire android {} DSL, but a library module has no applicationId, produces an AAR (Android Archive) instead of an APK/AAB, and is meant to be depended on rather than installed:

See Android Developers — Create an Android Library.

namespace plays the same role as in an application module — it is the package under which the library’s own R/BuildConfig classes are generated — but for a library it is also effectively part of the published artifact’s identity: consumers reference the library’s generated resources through this namespace (com.irurueta.android.glutils.R.drawable.foo), so renaming it after a release is a breaking change.

minSdk on a library is a floor that every consumer inherits: Gradle takes the highest minSdk across an app and all of its library dependencies as the effective minSdk for the whole build, so a library that sets minSdk = 26 silently raises the floor for any app that depends on it, even if that app’s own minSdk is lower. This creates a direct trade-off:

irurueta-android-glutils picks minSdk = 26 (Android 8.0), a common floor for general-purpose libraries in 2026 that balances device coverage against API modernity. A library author should document the chosen minSdk prominently, since it is invisible in the published artifact’s coordinates and only surfaces as a Gradle manifest merger error at the consumer’s build time if violated.

The choice between the api and implementation dependency configurations, introduced in Project Structure, Gradle and Build Variants for intra-project modules, has sharper consequences once the module is a published library, because the boundary now crosses a network, not just a Gradle project graph:

See Android Developers — Add build dependencies.

The rule for a library author is mechanical: if a dependency’s types appear in a public/open function signature, property type, or supertype that consumers can see, it must be api; everything else should default to implementation to keep the library’s own dependency changes from forcing every consumer to recompile against a new transitive version.

An application’s own proguard-rules.pro only shapes how R8 shrinks and obfuscates that app’s code. A library cannot predict how it will be minified inside someone else’s app, so it ships its own rule file that R8 automatically merges into the consuming app’s shrink pass:

See Android Developers — Optimization for library authors.

See Android Developers — Optimization for library authors.

A library typically leaves its own isMinifyEnabled = false (there is little to shrink in a single module, and shrinking would risk stripping symbols consumers still need), while consumer-rules.pro keeps the public API surface, any class accessed through reflection or JNI, and anything Parcelable/Serializable that R8 might otherwise remove or rename inside the app that eventually ships the code. See Android Developers — Create an Android Library and Building, Signing and Preparing a Release for R8 and shrinking in general.

Kotlin’s explicit API mode turns a library’s implicit visibility and return-type inference into compile errors, forcing every public/protected declaration to state its visibility and return type explicitly — it exists specifically for library authors, because an accidentally public function or an inferred return type that silently narrows on a later Kotlin version becomes a breaking change for consumers the moment it ships:

See Kotlin Documentation — Explicit API mode for library authors.

See Kotlin Documentation — Explicit API mode for library authors.

A companion practice for larger libraries is binary-compatibility validation (org.jetbrains.kotlinx.binary-compatibility-validator), a Gradle plugin that dumps the library’s public ABI to a checked-in .api file and fails the build if a later change alters that ABI without the file being deliberately updated — catching, for example, an accidental signature change that would break every consumer recompiling against the new version without a major version bump. See Kotlin — Explicit API Mode for Library Authors and Kotlin — Binary Compatibility Validator.

Before reaching Maven Central at all, a library needs a Gradle publication — a named bundle of the compiled AAR, its sources and its documentation that maven-publish (Gradle’s built-in publishing plugin) or a wrapper around it knows how to upload. AGP exposes this natively for library modules through the publishing {} block:

See Android Developers — Configure publishing variants.

singleVariant("release") tells AGP which build variant to publish (a library typically ships only one), while withSourcesJar()/withJavadocJar() attach a -sources.jar and a -javadoc.jar alongside the AAR — Maven Central requires both, as covered below. This raw maven-publish path is the right tool for publishing to a private or internal Maven repository (an organization’s own Artifactory/Nexus, or the maven { url = …​ } repository shown above); publishing to Maven Central itself adds enough additional requirements (namespace verification, GPG signing, a specific POM shape) that in practice almost nobody drives it through raw maven-publish, and instead uses a wrapper plugin such as vanniktech’s, covered next. See Android Developers — Configure Publishing Variants and Android Developers — Upload Your Library to a Maven Repository.

Javadoc for a Kotlin library is generated by Dokka, not the javadoc tool, since Kotlin’s Java-interop signatures and KDoc comments need a Kotlin-aware generator:

See Kotlin Documentation — Dokka Gradle plugin.

irurueta-android-glutils runs ./gradlew :lib:dokkaGenerate in CI and deploys the resulting HTML straight to GitHub Pages with crazy-max/ghaction-github-pages, giving the library a browsable API reference site alongside its Maven Central artifact. That CI workflow, and how Dokka’s Javadoc JAR feeds into publishJavadocJar below, is covered in CI/CD with GitHub Actions; this page only notes that the same Dokka output backs both the published -javadoc.jar and the public documentation site.

Maven Central is the default repository every Gradle/Maven build resolves from unless told otherwise, and publishing to it used to go through OSSRH (the OSS Repository Hosting Nexus instance at oss.sonatype.org). OSSRH was shut down on June 30, 2025; all publishing now goes through the Central Publisher Portal (https://central.sonatype.com/), a rewritten publishing pipeline with its own account system, tokens and validation rules, replacing the old Nexus staging-repository workflow entirely. See Central Sonatype — OSSRH End-of-Life and Central Sonatype — Central Publisher Portal.

Once a release is live on Maven Central (typically within minutes of publishAndReleaseToMavenCentral completing, or after the manual release step for publishToMavenCentral), any project resolving from mavenCentral() — already the default in a project scaffolded as shown in Project Structure, Gradle and Build Variants — can add it like any other dependency:

See Android Developers — Add build dependencies.

No special repository declaration is needed beyond the standard mavenCentral() entry, since the Central Publisher Portal is the publishing front end for the same Maven Central repository every Gradle build already resolves from by default.

Maven Central is the default choice for a public, general-purpose library, but three alternatives remain common for narrower cases:

JCenter, Bintray’s old default Maven repository, was shut down in 2021 and is unreachable; any project still referencing jcenter() in settings.gradle.kts or build.gradle.kts must remove it and resolve exclusively from google() and mavenCentral().

The two release paths converge once the Portal’s own validation (POM completeness, signatures, checksums, all covered above) passes — publishToMavenCentral only adds a human decision point before the same artifact becomes resolvable, while publishAndReleaseToMavenCentral removes that pause entirely for a fully hands-off release pipeline.