Multi-Module Architecture in Android: Pros, Cons, and Lessons

A single :app module is the right start for almost every project. As the app grows to dozens of screens and several developers, one module means every change recompiles everything, any class can depend on any other, and ownership is blurry. Modularization addresses those problems, at a price.

What modules give you

A typical structure

api vs implementation

plugins { id("app.android.feature") }        // convention plugin (see below)

dependencies {
    implementation(project(":core:data"))       // used internally: NOT exposed to consumers
    implementation(project(":core:designsystem"))
    api(project(":core:model"))                 // types appear in this module's public API
}

Prefer implementation. It keeps dependencies from leaking to consumers and limits recompilation when they change. Use api only when a dependency's types appear in your module's public signatures.

Convention plugins: avoid copy-pasted build files

class AndroidFeatureConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) = with(target) {
        pluginManager.apply("com.android.library")
        pluginManager.apply("org.jetbrains.kotlin.android")
        pluginManager.apply("org.jetbrains.kotlin.plugin.compose")
        extensions.configure<LibraryExtension> {
            compileSdk = 36
            defaultConfig.minSdk = 24
            buildFeatures.compose = true
        }
        dependencies {
            add("implementation", project(":core:designsystem"))
            add("implementation", project(":core:ui"))
        }
    }
}

Each new feature module then needs only a few lines. Google's Now in Android sample uses this approach.

Navigating between features without coupling

If :feature:home needs to open search, it shouldn't depend on :feature:search. Common approaches:

• Route keys in a shared module (:core:navigation), with each feature providing its entries, and :app assembling the graph.
• Lambdas passed from :app: HomeScreen(onOpenSearch = { backStack.add(Search) }).

Lessons learned

When it pays off

Frequently asked questions

Conclusion

Multi-module architecture trades build configuration effort for faster incremental builds, enforced boundaries and team ownership. Start simple, extract core modules first, use implementation by default and convention plugins for consistency, and never let features depend on each other.

Next step: choose how to slice the app in Modularization Strategies for Large Android Apps.