How to Create a Library Module for Android (2026 Guide)

To create a library module in Android Studio, open File > New > New Module, choose Android Library, give it a name, and finish. Android Studio swaps the com.android.application plugin for com.android.library, drops the applicationId, and your module now compiles to a reusable AAR (Android Archive) instead of an APK. You then add it to your app with a single line: implementation(project(":mylibrary")).

This 2026 guide uses the modern Kotlin DSL (build.gradle.kts) that ships by default in current Android Studio, and covers everything from your first module to publishing a versioned library other developers can pull from Maven Central or JitPack.

In a hurry? Jump to: What a library module is · App vs library module · Create one step by step · Add it to your app · Advanced features · Publish your library · How we tested · FAQ

What is a library module in Android?

A library module is a Gradle module that holds reusable code and Android resources but cannot be launched or installed on its own. Instead of producing an installable APK or App Bundle, it compiles into an AAR (Android Archive) file that other app modules consume as a dependency. Think of it as a private toolbox: you write a feature once — a custom view, a networking layer, an analytics wrapper — and reuse it across as many apps as you like.

It helps to know the two binary formats involved:

• JAR (Java ARchive) — a plain bundle of compiled Java/Kotlin bytecode. A JAR cannot contain Android resources, manifest entries, or assets, so it is only suitable for pure logic with no UI or resource dependencies.
• AAR (Android ARchive) — the Android-specific format. An AAR can contain compiled bytecode and resources (layouts, drawables, strings, colors), an AndroidManifest.xml, assets, and a R.txt file. This is what an Android library module builds.

Because a library module lives inside your project (or in a Maven repository), you can update it independently of the app that uses it. That is the same principle behind Google's AndroidX (Jetpack) libraries: they ship features and widgets that you pull in as dependencies rather than waiting for a new OS release.

The most common reasons to extract code into a library module are reuse across multiple apps, faster builds (Gradle can cache and parallelize unchanged modules), cleaner architecture (clear API boundaries between feature, data, and UI layers), and shipping an SDK for other developers to consume.

Android app module vs. library module

The single biggest difference is the Gradle plugin each module applies, and the artifact it produces. An app module is launchable and signable; a library module is not. Here is a side-by-side comparison.

Property	App module	Library module
Gradle plugin	com.android.application	com.android.library
Output artifact	APK / AAB (installable)	AAR (dependency only)
applicationId	Required	Not allowed
Launchable / installable	Yes	No
Can be signed for release	Yes	No (consumed, not shipped)
Has a launcher activity	Yes (entry point)	Optional, no entry point
Can contain resources	Yes	Yes
Consumer ProGuard rules	No	Yes (consumerProguardFiles)

Below are the two build files side by side, written in the modern Kotlin DSL (build.gradle.kts). Note the plugin id and the missing applicationId in the library.

App module — app/build.gradle.kts:

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 36
        versionCode = 1
        versionName = "1.0"
    }
}

dependencies {
    // ...
}

Library module — mylibrary/build.gradle.kts:

plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.mylibrary"
    compileSdk = 36

    defaultConfig {
        // No applicationId for library modules
        minSdk = 24
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        consumerProguardFiles("consumer-rules.pro")
    }
}

dependencies {
    // ...
}

As of 2026, compileSdk and targetSdk 36 (Android 16) is the current target — Google Play requires new apps and updates to target API level 36 from August 31, 2026, so it is worth standardizing on it across every module. A library's minSdk should be set as low as your real-world support floor allows; consuming apps cannot use a lower minSdk than any library they depend on.

How to create a library module step by step

Android Studio scaffolds the whole module for you. Here is the reliable path.

1. Add the new module

Open File > New > New Module. In the templates list, select Android Library (not Java or Kotlin Library — that produces a plain JAR with no resource support). Give it a module name such as mylibrary, set a unique package name, choose your minimum SDK, and click Finish. The module package name must be globally unique within the project.

2. Confirm the module was registered

Modules are declared in the root settings.gradle.kts. Android Studio adds your new module automatically:

// settings.gradle.kts
include(":app")
include(":mylibrary")

3. (Alternative) Convert an existing app module into a library

If you started with an app module and want to demote it to a library, open its build.gradle.kts, change the plugin from com.android.application to com.android.library, delete the applicationId line, then click File > Sync Project with Gradle Files. That is the entire conversion.

4. Add functionality

Drop your reusable code into the module's src/main folder. A simple Kotlin utility object:

// mylibrary/src/main/java/com/example/mylibrary/MathUtils.kt
package com.example.mylibrary

object MathUtils {
    fun add(a: Int, b: Int): Int = a + b
    fun subtract(a: Int, b: Int): Int = a - b
}

5. Build the AAR (optional)

For a local project(...) dependency you do not need to build the AAR manually — Gradle wires it up. But if you want the .aar file itself (to share it or upload it), select the library module in the Project window and use the Build menu, or run ./gradlew :mylibrary:assembleRelease. The output lands in mylibrary/build/outputs/aar/.

Also Read: How to Convert Kotlin to Java Code in Android Studio

How to add the library module to your app

There are three ways to consume a library, depending on where it lives.

Local module dependency (same project)

This is the most common case for multi-module projects. In your app's build.gradle.kts:

// app/build.gradle.kts
dependencies {
    implementation(project(":mylibrary"))
    // other dependencies...
}

Now call into the library from your app, exactly as you would any other dependency:

// app/src/main/java/com/example/myapp/MainActivity.kt
package com.example.myapp

import android.os.Bundle
import android.widget.TextView
import androidx.appcompat.app.AppCompatActivity
import com.example.mylibrary.MathUtils

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val sum = MathUtils.add(5, 3)
        val difference = MathUtils.subtract(10, 4)

        findViewById<TextView>(R.id.resultTextView).text =
            "Sum: $sum, Difference: $difference"
    }
}

Local AAR or JAR file

If someone hands you a prebuilt .aar or .jar, drop it into the app module's libs/ folder and reference it:

dependencies {
    implementation(files("libs/mylibrary.aar"))
    // or pull in everything in libs/
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar", "*.aar"))))
}

Remote dependency (published library)

Once a library is published to Maven Central or JitPack, consumers add a single coordinate — covered in the publishing section below.

Advanced library module features

Because an AAR can carry resources and a manifest, a library module can ship far more than utility functions.

Custom views

Ship a reusable widget that any app can drop into a layout:

// mylibrary/src/main/java/com/example/mylibrary/CustomButton.kt
package com.example.mylibrary

import android.content.Context
import android.util.AttributeSet
import androidx.appcompat.widget.AppCompatButton

class CustomButton @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : AppCompatButton(context, attrs, defStyleAttr) {
    init {
        isAllCaps = false
        setPadding(20, 10, 20, 10)
    }
}

Resource files

Add colors, strings, dimensions, and drawables under the library's res/ folder. To avoid name collisions with the consuming app, prefix your resource names (for example mylib_primary):

<!-- mylibrary/src/main/res/values/colors.xml -->
<resources>
    <color name="mylib_primary">#3F51B5</color>
</resources>

You can also create res/values/public.xml to mark certain resources as the library's public API and keep the rest private — a good habit when shipping an SDK.

Callback interfaces

Expose a clean asynchronous API with an interface and a coroutine-friendly fetcher:

// mylibrary/src/main/java/com/example/mylibrary/DataFetcher.kt
package com.example.mylibrary

import android.os.Handler
import android.os.Looper

interface DataFetchCallback {
    fun onSuccess(data: String)
    fun onError(message: String)
}

object DataFetcher {
    fun fetchData(callback: DataFetchCallback) {
        Handler(Looper.getMainLooper()).postDelayed({
            // Simulating a network call
            callback.onSuccess("Data fetched successfully")
        }, 2000)
    }
}

Use Gradle version catalogs for shared dependencies

In a real multi-module project, keep dependency versions in one place using a version catalog (gradle/libs.versions.toml). Every module then references the same alias — implementation(libs.androidx.appcompat) — so upgrades happen once. For larger codebases, Gradle convention plugins let you share an entire library build configuration (compileSdk, Kotlin options, common dependencies) across every module instead of copy-pasting it.

How to publish your Android library

To let other developers depend on your library by coordinate, publish it to a Maven repository using the maven-publish Gradle plugin. There are two mainstream destinations in 2026: JitPack (easiest) and Maven Central (the recommended, more trusted home for public libraries).

Configure maven-publish in the library

// mylibrary/build.gradle.kts
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
    id("maven-publish")
}

afterEvaluate {
    publishing {
        publications {
            create<MavenPublication>("release") {
                from(components["release"])
                groupId = "com.github.yourusername"
                artifactId = "mylibrary"
                version = "1.0.0"
            }
        }
    }
}

Publish with JitPack

JitPack is the fastest route: it builds your library straight from a GitHub tag, no account credentials needed. Push your code to GitHub, create a release tag, and consumers add the JitPack repository plus your coordinate:

// settings.gradle.kts (consumer project)
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
        maven { url = uri("https://jitpack.io") }
    }
}

// consumer app/build.gradle.kts
dependencies {
    implementation("com.github.yourusername:mylibrary:1.0.0")
}

JitPack vs. Maven Central in 2026

The two differ in trust and reproducibility, and that matters when you ship a public SDK:

• JitPack builds artifacts on demand from your GitHub source. It is effortless to set up, but a given version can technically change if the source repository changes, and it carries less trust for production SDKs.
• Maven Central hosts cryptographically signed, immutable artifacts — version 1.0.0 is always the exact same bytes. It is now the recommended destination for public libraries (consumers get it via the default mavenCentral() with no custom repository line). The trade-off is a stricter one-time setup: a namespace, GPG signing keys, and the Central Publisher Portal.

For an internal team library, a local project(":mylibrary") dependency is all you need — publishing only matters when external developers must consume it.

Related reading on AndroidHire

• Convert Kotlin to Java code in Android Studio
• How to add R8 code shrinking in Android Studio
• Handle Android runtime permissions with the Dexter library
• Retrofit networking tutorial in Kotlin

How we tested this guide

We verified every step in a fresh multi-module project built with the current stable Android Studio using the Kotlin DSL. We created an Android Library module through File > New > New Module, confirmed it registered in settings.gradle.kts, and checked that Android Studio applied com.android.library and stripped the applicationId automatically. We then added Kotlin utilities, a custom view, and prefixed resources, wired the library into an app module via implementation(project(":mylibrary")), and ran a successful build calling library code from MainActivity.

We assembled the release AAR with ./gradlew :mylibrary:assembleRelease to confirm the output format, cross-checked the plugin ids, namespace, consumerProguardFiles, and AAR-vs-JAR behavior against Google's official “Create an Android library” documentation, and confirmed the API level 36 (Android 16) Google Play targeting deadline of August 31, 2026, along with the current JitPack and Maven Central publishing flows. Code samples were modernized from Java to idiomatic Kotlin, which is Google's recommended language for Android.

Bottom line

Creating a library module is one of the highest-leverage moves in Android development: it turns one-off code into a reusable, independently versioned asset and keeps large projects fast and maintainable. For most teams the workflow is simple — File > New > New Module > Android Library, add your code, and depend on it with implementation(project(":mylibrary")). Reach for the maven-publish plugin only when external developers need to consume it, choosing Maven Central for a trusted public SDK or JitPack for the quickest path from a GitHub tag. Standardize on the Kotlin DSL, compileSdk 36, and version catalogs, and your modules will stay clean as your codebase grows.