Android and JVM developers run into a specific flavour of disk pressure that JavaScript and Python developers mostly don't: Gradle doesn't just cache your dependencies, it also caches entire versions of itself, once per project that pins a different Gradle version. Between the two, ~/.gradle can quietly become one of the largest developer-tooling folders on the machine.

What's inside ~/.gradle/caches

Gradle's dependency and build caching lives at ~/.gradle/caches, organised into subfolders by Gradle version (since cache formats can change between versions) and then further by content type:

  • modules-2 — downloaded dependency artefacts (JARs, AARs for Android, sources and Javadoc jars if you've pulled them), plus module metadata describing each dependency's own transitive requirements. This is the equivalent of npm's or Maven's package cache.
  • Build cache — task output caching, where Gradle stores the results of previous build tasks (compiled classes, processed resources) so that a rebuild with unchanged inputs can reuse the output rather than redoing the work. This is what makes Gradle's incremental builds fast, and it's also often the largest single contributor to the cache's overall size on an actively developed Android project.
  • Transforms cache — results of "artifact transforms", a Gradle mechanism for converting dependencies between forms (for example, extracting an AAR's classes for a specific build variant), cached so the transform doesn't re-run every build.

Check the size directly:

du -sh ~/.gradle/caches

On an actively used Android development machine, this routinely reaches several gigabytes and sometimes tens of gigabytes, particularly if you work across multiple Gradle versions (common when maintaining several projects pinned to different Android Gradle Plugin versions).

Gradle wrapper distributions: a separate, often-overlooked cost

Sitting alongside the caches folder, ~/.gradle/wrapper/dists/ holds full, unpacked copies of every specific Gradle version any project's wrapper (gradlew) has ever asked for. Because most projects pin an exact Gradle version through gradle-wrapper.properties rather than "whatever's installed", and because that pinned version changes as projects upgrade over time, it's common to accumulate half a dozen or more full Gradle distributions here, each several hundred megabytes.

du -sh ~/.gradle/wrapper/dists/*

will show you exactly which versions are installed and how large each is. Unlike the dependency cache, wrapper distributions don't dedupe partial content — each version is a complete, independent copy of the Gradle binary distribution.

Clearing the caches safely

The entire ~/.gradle/caches folder can be deleted:

rm -rf ~/.gradle/caches

Gradle rebuilds whatever it needs — re-downloading dependencies, re-running transforms, repopulating the build cache — the next time you build any project. The cost is purely time: your next build for every project becomes a cold build rather than benefiting from any previously cached work.

For wrapper distributions, you can safely delete versions no active project requires:

rm -rf ~/.gradle/wrapper/dists/gradle-7.6-bin

Gradle re-downloads that exact version automatically the next time a project's wrapper needs it — this is precisely what the wrapper mechanism is designed to guarantee, which is part of why it's safe to delete freely.

--refresh-dependencies: often a better fix than deleting anything

A common but usually wrong instinct when a build behaves unexpectedly (a dependency seems to be resolving to the wrong version, or a SNAPSHOT dependency isn't picking up a recent change) is to nuke the entire cache. In most cases, the more targeted fix is:

./gradlew build --refresh-dependencies

This tells Gradle to bypass its cached metadata about whether a dependency needs re-checking against its remote repository, forcing a re-verification for the current build, without discarding the entire local cache of every dependency you've ever resolved. It resolves the specific class of problem — a SNAPSHOT or dynamic version (1.+) that has genuinely changed upstream but whose cached metadata says otherwise — without the time cost of a full cold rebuild across every dependency.

Reach for --refresh-dependencies first; reach for deleting ~/.gradle/caches only when you want the disk space back or --refresh-dependencies genuinely didn't resolve the issue.

Per-project .gradle and build folders are separate again

Just like Cargo's target or a JavaScript project's node_modules, each individual project also has its own local .gradle/ folder (project-specific configuration cache and metadata) and a build/ folder (compiled output specific to that project) sitting inside the project directory itself, entirely separate from the shared ~/.gradle home. These are often significant contributors in their own right, especially for Android projects with multiple build variants, each producing its own set of build outputs.

find ~ -type d -name build -path "*/app/build" -prune -exec du -sh {} \;

is a rough way to spot Android app module build folders specifically, though the pattern needs adjusting depending on your project layout.

The Gradle daemon and its own memory-mapped state

Separate from anything on disk, Gradle runs a background daemon process to speed up successive builds by keeping the JVM warm between invocations. This isn't a disk-space concern directly, but it does maintain some state under ~/.gradle/daemon/ — mostly small log and PID-tracking files rather than anything substantial — and stopping stale daemons (./gradlew --stop, or simply restarting your Mac) is worth doing occasionally if you notice several daemon processes accumulating in Activity Monitor, particularly after switching between projects pinned to different Gradle versions, each of which spins up its own daemon rather than sharing one across versions.

Android Studio adds its own layer on top of Gradle's

If you use Android Studio specifically, note that it maintains its own IDE-level caches (covered in the broader JetBrains caches discussion, since Android Studio is built on the same platform as IntelliJ) in addition to everything Gradle itself manages. A slow or bloated Android project's disk footprint is often the combination of both — Android Studio's own index cache under ~/Library/Caches/Google/AndroidStudio*, plus the Gradle-specific caches covered here — and clearing one without the other only tells half the story if you're chasing overall project-related disk usage rather than a Gradle-specific build problem.

A practical routine

  1. du -sh ~/.gradle/caches and du -sh ~/.gradle/wrapper/dists/* to see the scale of each.
  2. Delete wrapper distributions for Gradle versions no current project actually pins.
  3. Try --refresh-dependencies on a specific project before deleting the shared cache if you're chasing a resolution problem rather than just reclaiming space.
  4. For general disk pressure, rm -rf ~/.gradle/caches is safe and reclaims the most space in one step.
  5. Separately check per-project build/ folders for anything you're not actively working on.

Where VolumeLens fits in

Between the shared ~/.gradle cache, wrapper distributions for old Gradle versions, and per-project build folders scattered across every Android or JVM project you've cloned, the total Gradle footprint on a developer's Mac is rarely visible in one place. VolumeLens draws all of it to scale in a single scan, so you can see the shared cache next to the per-project build outputs without hunting through several separate paths. Check what's included in Insights for automatic recognition of Gradle and other JVM tooling caches.