I Audited Google’s “Now in Android” Build Architecture (Here is what I found)

The Black Box of Gradle Builds As Android applications grow, they inevitably turn into deeply nested, multi-module mazes. You start with a clean architecture, but fast forward 6 months, and you are staring at a 5-minute build time, wondering where it all went wrong.

Is it a circular dependency? Is a rogue module breaking the Configuration Cache? Are we still running KAPT when we don’t need to?

For a long time, answering these questions required digging through Gradle build scans and manually tracking build.gradle files. Web developers have had "Google Lighthouse" for years to instantly audit their site’s health. I realized Android developers needed the exact same thing for their build systems.

So, I built Gradle Lighthouse — an open-source, zero-configuration build intelligence plugin.

To test if it was truly enterprise-ready, I decided to point it at the gold standard of modern Android architecture: Google’s Now in Android (NIA) repository.

The Experiment: Auditing “Now in Android”
The Now in Android app is Google’s official showcase for modern Android development. It uses Jetpack Compose, a highly modularized architecture, and Kotlin Multiplatform. It is the perfect stress test.

I added the Gradle Lighthouse plugin to NIA’s root build.gradle.kts (it only takes one line) and ran ./gradlew lighthouseAudit.

The engine ran 20+ architectural checks across the entire module graph. I expected a perfect score. I was wrong.

The Results: NIA Scored a 50/100 (“At Risk”)

The NIA project received an overall Architecture Score of 50/100, placing it in the “At Risk” rank.

Wait, how is the official Google showcase app at risk? Lighthouse runs an incredibly strict set of rules. Here are the most fascinating flaws it uncovered in NIA’s build scripts:

1. Configuration Cache Blockers (allprojects anti-pattern) Lighthouse immediately flagged a critical error: the root build.gradle.kts uses allprojects{} or subprojects{} blocks.

The Impact: This forces Gradle to eagerly configure every single module, even if you are only building one. It actively blocks migration to the Configuration Cache and the upcoming Isolated Projects feature in Gradle 9.x.
The Fix: Replacing this with convention plugins reduces configuration time by 50–90%.

1. The “Dark Module” Test Lighthouse scans for “Dark Modules” — modules that exist in the graph but have absolutely zero test files. The root nowinandroid module was flagged as a completely untested risk vector. In large enterprise projects, these dark modules accumulate over time and make safe refactoring impossible.

Subscribe to the Medium newsletter

1. Version Catalog Clutter & Bundle Opportunities NIA uses a modern libs.versions.toml file, but Lighthouse found two major areas for hygiene improvement:

Unused Entries: The catalog defines 103 library entries, but Lighthouse warned that several appear to be unused across the graph, creating unnecessary noise during dependency upgrades.
Missed Bundles: Lighthouse found 9 bundle opportunities. For instance, NIA declares 50 different androidx libraries and 3 coil libraries individually across modules, instead of grouping them into [bundles] for cleaner, safer dependency management.

1. Security and Reproducibility Blindspots Finally, Lighthouse flagged two easily fixable security and stability issues:

No Dependency Locking: NIA doesn’t use dependencyLocking. This means a transitive dependency could be silently upgraded to a compromised version between builds.
No JDK Toolchain: The build scripts lack a pinned JVM Toolchain (kotlin { jvmToolchain(17) }), which can lead to inconsistent bytecode across different developers' machines.
The Takeaway for Your App
Google’s Now in Android is a fantastic repository, but it proves a crucial point: As a project scales, build hygiene degrades silently.

The difference between a legacy app and a highly scalable one is often just 50ms of build time compounded over 100 modules. But you can’t fix what you can’t measure.

Get Your Lighthouse Score
I built Gradle Lighthouse to be completely free, open-source, and plug-and-play. If you want to see your project’s score and find out exactly why your builds are slow, it takes exactly one line of code.

Add this to your build.gradle.kts:

plugins {
  id("io.github.dev-vikas-soni.lighthouse") version "2.1.1"
}

And run:

./gradlew lighthouseAudit

Check out the repository here, and let me know what score your project gets!

🔗 GitHub: Gradle Lighthouse

(⭐️ If this tool helps you clean up your build graph and save time, I’d deeply appreciate a star on GitHub to help the open-source project grow!)