Scaling Android Apps with Gradle: Different Source Sets (Part 2)
Article Summary
OLX Engineering scaled their Android app across multiple markets without creating code chaos. Here's how they used Gradle source sets to keep things clean.
This is Part 2 of OLX's series on scaling Android apps with Gradle. While Part 1 covered build types and product flavors, this deep dive shows how different source sets let you compile only what each variant needs.
Key Takeaways
- Source sets follow strict priority: build variant > build type > product flavor > main
- Debug builds include LeakCanary and Chucker; release builds get empty placeholder methods
- Firebase In-App Messaging ships only to specific flavors using dedicated source sets
- Flavored manifests override the base Application class with tools:replace attribute
- Duplicate Java class names across source sets trigger compile errors
Gradle source sets let you organize code by build variant, compiling only what's needed while maintaining flexibility without maintenance overhead.
About This Article
OLX needed to keep debugging libraries like Stetho and LeakCanary out of release builds to reduce size, but include them in debug builds. The challenge was that both build variants needed the same method signatures with different implementations.
Sahil Jain's team set up separate source directories for debug and release builds. Each contained a LibUtil.kt file with identical method signatures. The debug version initialized the libraries while the release version used empty placeholder methods.
This eliminated runtime conditionals and build-time property checks. Gradle compiled only the code needed for each variant. The single codebase structure scaled across multiple build types without extra maintenance work.