If you’ve ever worked on a large-scale mobile ecosystem — think ride-hailing apps like Rapido— you’ve likely dealt with multiple apps (Customer, Captain (Driver App)) and a bunch of shared SDKs: Location SDK, Chat SDK, Comms SDK, etc.

As SDK developers, our daily job often looks like this:

• Fix a bug in the SDK
• Publish it to a Maven local or GitHub package
• Pull the new version into the main app (say, the Captain (Driver) App)
• Rebuild, integrate, and test

Sounds straightforward, right? Until you do this 10 times a day. 😅

Publishing, syncing dependencies, waiting for builds, and the biggest pain — not being able to debug SDK code directly — makes this process painfully slow.

That’s where Gradle Composite Builds come in. They can completely change the way you integrate and test SDKs locally.

🌱 The Traditional Way (and Its Pain)

Before composite builds, there were two common approaches:

1. Maven Local Publication

You’d build and publish your SDK to the local Maven repository:

./gradlew publishToMavenLocal

 

Then, in your feature module:

implementation("com.rapido:chat-sdk:1.0.1")

 

This works fine, but every small SDK change means re-publishing and syncing again. Plus, you can’t place breakpoints inside your SDK when debugging from your app.

2.GitHub (or Remote) Publication

You push your SDK build to a remote Maven repository (like GitHub Packages, Artifactory, or JitPack).

This helps share SDKs across teams, but it’s even slower — you need version management, credentials, and it’s not ideal for rapid iteration.

⚡ The Modern Way — Gradle Composite Builds

Composite builds let you include other Gradle projects (like your SDKs) directly into your main app without publishing them anywhere.

They work seamlessly across multiple modules or repositories and make debugging & testing SDKs a breeze.

Here’s how you can set it up 👇

🧩 Setting Up Composite Builds (with Kotlin DSL)

Let’s say you have the following projects:

root/
├── apps/
│ └── captain-app/ ← (Driver App)
├── sdks/
│ ├── chat-sdk/
│ ├── location-sdk/
│ └── comms-sdk/

 

You want your Captain (Driver) App to use chat-sdk as a dependency — but instead of fetching it from Maven, you want to use your local source.

Example (Setup)

Here’s how we use composite builds internally at Rapido for testing SDKs locally without publishing them.

// =============================================================================
// Composite Build for Local SDK Testing
// =============================================================================
// This allows testing local changes in platform-mobile-sdks without publishing
// Path: ../platform-mobile-sdks is relative to this project's root
// To disable: Comment out this entire block
// =============================================================================
includeBuild("../platform-mobile-sdks") {
dependencySubstitution {
// Substitute network-kmm with local network module
substitute(module("com.rapido.sdk:network-kmm"))
.using(project(":network"))

// Substitute chat-kmp-sdk with local chat-kmp-sdk module
substitute(module("com.rapido.sdk:chat-kmp-sdk"))
.using(project(":chat-kmp:chat-kmp-sdk"))
}
}

 

This snippet does two key things:

1. Includes the platform-mobile-sdks build directly.
2. Substitutes published dependencies (network-kmm, chat-kmp-sdk) with their local project versions.

With this setup, your main app (Driver App) uses the live source of these SDKs — making it easy to test, debug, and iterate instantly.

🧠 Why This Is a Game-Changer

1. Instant Integration Testing: You can make SDK changes and immediately test them inside your main app — no publishing, no version bumping.
2. True Source-Level Debugging: Set breakpoints directly inside SDK code while running the app. Android Studio will treat SDK code like part of your main project.
3. Faster Build Cycles: Since no publishing or downloading is required, you save minutes (or hours) in a dev cycle.
4. Cleaner Collaboration: Multiple SDK teams can work together locally without fighting over Maven versions or GitHub releases.
5. Safer Refactoring: If you change a shared interface in the SDK, you can immediately verify its impact in the main app.

🧩 Bonus Tip: Working with Multiple SDKs

You can composite multiple SDKs in one go:

includeBuild("../sdks/chat-sdk")
includeBuild("../sdks/location-sdk")
includeBuild("../sdks/comms-sdk")

 

Gradle will resolve all these builds together as if they were part of one big project. This setup is perfect for mobile companies, where SDKs evolve rapidly and need to stay in sync across multiple apps.

🧮 Traditional vs Composite Build — Visual Overview

Here’s a simple diagram comparing both approaches 👇

No publishing. No version bumps. Just instant integration. ⚡

🏁 Conclusion

Gradle Composite Builds are one of those underused gems that can massively improve your SDK development workflow.

If you’re tired of constantly publishing artifacts just to test minor changes — it’s time to give composite builds a try.

They’re fast, local, and developer-friendly — exactly what modern mobile development needs.

🚀 TL;DR

• Composite builds let you link SDK source projects directly — no need for Maven publication.
• You get instant integration testing, full debugging, and faster iteration cycles.
• Perfect for large-scale mobile ecosystems with multiple internal SDKs.

Big thanks to @avishekdas128 for the support and for helping me try this out!

 

This article was previously published on proandroiddev.com