Mastering Dependencies in Multi-Module Android Projects: Strategies for Sanity & Scale

If you’ve ever stared at a build.gradle file that feels longer than War and Peace, you already know how messy dependency management can get in a large, multi-module Android project. Version mismatches, transitive dependency nightmares, duplicate libraries bloating your APK — and let’s not forget the mental gymnastics of figuring out where on earth a version is actually defined.

I’ve been there too (and earned a few gray hairs along the way). Over time, though, I’ve picked up some practical strategies to tame this beast — and today, I’m excited to share them with you. Whether you’re building a startup app from scratch or refactoring a sprawling legacy codebase, these tips will help you keep your builds clean, predictable, and easy to maintain.

So, let’s dive in!

Why Multi-Module? And Why is Dependency Management Harder Here?

Multi-module architectures are awesome. They:

• Improve build times (via parallelism & incremental builds),
• Help enforce modularity & separation of concerns,
• Make your codebase more testable & maintainable.

But they also spread your dependencies everywhere. Without a strategy, you’ll quickly end up with:

• Same dependency declared in 20 places.
• Different versions of the same library causing conflicts.
• Poor visibility of what versions are actually being used.

Sound familiar? Let’s fix it.

Strategies for Dependency Management

1. Centralized ext in root build.gradle

The simplest and most common approach is to declare your dependency versions in the ext block of the root build.gradle.

// root build.gradle
ext {
    versions = [
        kotlin      : "1.9.0",
        coroutines  : "1.7.3",
        retrofit    : "2.9.0"
    ]
}

And then reference them in your modules:

implementation "org.jetbrains.kotlin:kotlin-stdlib:${versions.kotlin}"
implementation "com.squareup.retrofit2:retrofit:${versions.retrofit}"

Benefits:

• Centralized version management.
• Easy to update versions in one place.
• No additional structure needed.
• Works out-of-the-box with Groovy-based projects.

When to choose:

• You’re working on a small-to-medium project.
• The team is still using Groovy build scripts.
• You want something quick and simple without extra tooling.

2. Separate dependencies.gradle File

You can go a step further by creating a dedicated dependencies.gradle file and applying it in your root build.gradle.

// dependencies.gradle
ext {
    versions = [...]
    libs = [
        kotlinStdlib: "org.jetbrains.kotlin:kotlin-stdlib:${versions.kotlin}",
        retrofit: "com.squareup.retrofit2:retrofit:${versions.retrofit}"
    ]
}

Then in your modules:

implementation libs.kotlinStdlib
implementation libs.retrofit

Benefits:

• Cleaner root build.gradle.
• Better separation of concerns.
• Still very simple.

When to choose:

• Your project is growing, and the ext block in build.gradle is getting cluttered.
• You want to keep build.gradle files concise while staying in Groovy.

3. buildSrc Directory

For larger projects, Gradle’s buildSrc directory offers a powerful, type-safe way to manage dependencies.

Create buildSrc/src/main/kotlin/Dependencies.kt:

object Versions {
    const val kotlin = "1.9.0"
    const val coroutines = "1.7.3"
}

object Deps {
    const val kotlinStdlib = "org.jetbrains.kotlin:kotlin-stdlib:${Versions.kotlin}"
    const val coroutines = "org.jetbrains.kotlinx:kotlinx-coroutines-core:${Versions.coroutines}"
}

Then in your modules:

implementation(Deps.kotlinStdlib)
implementation(Deps.coroutines)

Benefits:

• Type-safe and compile-time checked.
• IDE autocompletion and navigation.
• Cleaner and more maintainable for large teams.
• Works well with Kotlin DSL.

When to choose:

• Your project is large, with dozens of modules and many dependencies.
• The team uses Kotlin DSL or plans to migrate to it.
• You want maximum safety, maintainability, and IDE support.

4. Using BOM (Bill of Materials)

For libraries that release many artifacts (like Firebase or OkHttp), you can use a BOM to ensure all artifacts are on the same version.

implementation platform("com.squareup.okhttp3:okhttp-bom:4.12.0")
implementation "com.squareup.okhttp3:okhttp"
implementation "com.squareup.okhttp3:logging-interceptor"

Benefits:

• Eliminates version mismatch within a library ecosystem.
• Reduces boilerplate — you only specify the BOM version.

When to choose:

• You’re using libraries that officially publish BOMs.
• You want to simplify dependency declarations for libraries like Firebase or OkHttp.

5️. Enforce Constraints

You can enforce strict version constraints so that no module can accidentally use the wrong version of a library.

dependencies {
    constraints {
        implementation("com.google.code.gson:gson:2.10") {
            because("We want all modules to use the same version.")
        }
    }
}

Benefits:

• Guarantees consistency across modules
• Prevents accidental downgrades/upgrades.

When to choose:

• You’re maintaining a legacy project where modules already declare their own dependencies.
• You want to enforce policies without refactoring every module at once.

🔗 Final Thoughts

Dependency management isn’t just about cleaner build.gradle files — it’s about keeping your builds fast, reliable, and easy for everyone on the team to understand.

The sooner you adopt a strategy that fits your project size and team needs, the fewer headaches you’ll have down the road.

If you found this helpful, feel free to clap, share your thoughts, or drop your own tips & horror stories in the comments below.

Happy building! 🌟