Gradle Build Cache Retry Handling of Partial Writes in Android Studio Flamingo

Direct answer

Gradle does not retry a failed partial write to the build cache, and it does not need to. Build cache entries are written atomically and validated on read. If an entry is incomplete or corrupted, Gradle treats it as a cache miss and rebuilds the task instead of reusing it. There is no configuration to enable an additional automatic cleanup of corrupted cache entries beyond this validation.

The experimental flag android.experimental.enableBuildCache in the Android Gradle Plugin era of Android Studio Flamingo controls whether AGP participates in Gradle’s build cache. It makes cached outputs immutable for the duration of a build and does not add retry or rollback logic for partially written files. A partial write before a retry is therefore handled by the normal cache validation path, not by the flag.

Confirmed facts

• Gradle writes build cache entries via a temporary file followed by an atomic rename. The entry is only visible after the rename completes.
• On read, Gradle validates entries using stored metadata and checksums. A corrupted or incomplete entry is treated as a miss and discarded, forcing a rebuild.
• Android Studio Flamingo ships with Gradle 7.5+ and AGP 8.0+. Local build caching is enabled by default in new projects via org.gradle.caching=true. No documented automatic retry of a failed partial write exists in this Gradle line.

Likely explanation for the observed symptom

Partial writes typically arise from disk full, process kill, or I/O error during the write phase, not from a transient network fetch. Gradle does not re-attempt the write. A failed write fails the task or leaves a temp file behind. Subsequent reads detect the mismatch and force a rebuild. For a remote build cache the client may retry network operations, but partial file writes in the local cache directory are not retried by Gradle; the entry is considered invalid until a correct entry is written.

Steps needed for this case

1. Confirm version and cache type. Run ./gradlew --version and note whether the build uses local cache only or a remote build cache.
2. Verify caching is enabled and locate the cache. Check org.gradle.caching=true in gradle.properties and the cache directory, typically .gradle/caches/build-cache-1.
3. Reproduce with diagnostics. Run a build with --info and look for cache write and cache entry messages indicating miss, corrupted, or validation failure.
4. If corruption recurs, remove the local build cache in a controlled way and rebuild: delete the build-cache directory and run a clean build, then re-enable caching. Ensure stable disk space and I/O during the build.

Assumption: you are referring to the Gradle build cache for task outputs, not dependency artifact downloads. Dependency resolution uses separate retry and checksum logic.

One missing diagnostic detail that changes the recommendation: the exact Gradle version from ./gradlew --version and whether the cache in use is local or remote, plus an --info log snippet showing the cache error. Behavior is version-sensitive and differs between local and remote cache.