Gradle Configuration Cache: Measure Reuse and Fix Incompatible Tasks

Measure the correct thing

The configuration-cache guide explains compatibility and invalidation. A faster second build alone does not identify which mechanism helped.

Run a controlled comparison

./gradlew :app:assembleDebug --configuration-cache
./gradlew :app:assembleDebug --configuration-cache

Keep the same environment and requested tasks. Inspect whether Gradle stored and then reused the configuration entry. Do not compare a cold dependency download with a warm build and attribute the entire difference to configuration caching.

Read the incompatibility report

Tasks that access project state during execution or depend on undeclared configuration inputs may be incompatible. Use the generated report to identify the owning task or plugin.

Prefer a supported plugin update or a correct task implementation over globally suppressing problems. Custom tasks should use declared inputs, outputs and supported providers rather than reaching back into mutable project configuration at execution time.

Preserve build correctness

A cache hit is not the only acceptance criterion. Change a relevant input and verify that Gradle invalidates or reconfigures appropriately. A task that reuses stale configuration can produce the wrong artifact quickly.

The Gradle performance guide recommends measurement rather than speculative flags. Benchmark a representative set of developer and CI tasks.

Document the result

Record Gradle, AGP, JDK, task invocation, cache reuse and measured timings. APKLint's Build Analyzer can help inspect custom task patterns, but it cannot reproduce your environment or prove cache correctness from a build fragment. Keep the actual Gradle reports with the optimization change.