Gradle and Android Studio.
The cache that keeps growing.

Gradle keeps everything it shares between projects in one folder in your home directory, ~/.gradle, which Gradle's documentation calls the Gradle User Home. If you set the GRADLE_USER_HOME environment variable, it lives there instead. The folders that grow are these:

Each project adds two more: build/ in every module, with compiled classes, APKs and test reports, and a .gradle/ folder at the project root with state for incremental builds and the configuration cache.

Start with the totals, then see which part is heavy:

du -sh ~/.gradle/caches ~/.gradle/wrapper/dists
du -sh ~/.gradle/caches/*/ ~/.gradle/wrapper/dists/*/ | sort -h

On the Mac this guide was checked on, modules-2 took 2.9 GB, and six version folders from 8.10.2 to 9.7.1 sat next to five wrapper distributions. The -bin distributions took about 150 MB each; the -all ones, which include sources and documentation, between 495 and 574 MB.

To find out which versions your projects still use, read their wrapper settings. Replace ~/code with the folder where you keep your projects:

grep -h distributionUrl ~/code/*/gradle/wrapper/gradle-wrapper.properties | sort | uniq -c

Any version in the cache that no project names is a leftover.

It does, and knowing the rules explains why the folder still grows. Gradle's cache cleanup runs in the background when a daemon stops, at most once every 24 hours. By default it removes:

• a version folder in caches/ after 30 days without use (7 days for snapshot versions);
• a wrapper distribution once its version folder is gone;
• downloaded dependencies not used for 30 days, and files Gradle created itself after 7 days;
• build cache entries not used for 7 days, and daemon logs older than 14 days.

So the cleanup only happens when you run Gradle, and anything a build touched in the last month stays. If you switch between several Gradle versions, or between projects with different dependency versions, all of them stay warm.

You can change the retention periods with an init script in ~/.gradle/init.d. Gradle reads these settings only from there, not from a project's gradle.properties. They need Gradle 8.0 or later:

// ~/.gradle/init.d/cache-settings.init.gradle.kts
beforeSettings {
    caches {
        releasedWrappers.setRemoveUnusedEntriesAfterDays(14)
        downloadedResources.setRemoveUnusedEntriesAfterDays(14)
        createdResources.setRemoveUnusedEntriesAfterDays(5)
        buildCache.setRemoveUnusedEntriesAfterDays(5)
    }
}

Shorter periods free space sooner, at the price of downloading again what you need after a break. Setting cleanup = Cleanup.ALWAYS in the same block runs the cleanup at the end of every build instead of once a day, which makes builds slower.

Yes. Everything in ~/.gradle/caches and ~/.gradle/wrapper/dists is either downloaded or generated, and Gradle puts it back on the next build. What you lose is time and network:

• The next build of each project downloads its Gradle distribution and every dependency again.
• The first build after that is a cold one: no build cache, scripts compiled again, transforms run again.
• Until you have built once with a connection, --offline builds fail, so don't clear it right before a flight.

Keep ~/.gradle/gradle.properties and ~/.gradle/init.d: they are your settings, not cache. Signing settings and repository credentials are often kept in that properties file.

Stop the daemons first, so nothing writes into the cache while you delete it. In a project, run:

./gradlew --stop

That stops only the daemons of that project's Gradle version. To see the others, run jps, which comes with the JDK: live daemons appear as GradleDaemon. Quit Android Studio or IntelliJ IDEA too, since they start daemons of their own.

Go from the cheapest removal to the most expensive. First, versions no project uses. With the version numbers you found above, for example 8.10.2:

rm -rf ~/.gradle/caches/8.10.2 ~/.gradle/wrapper/dists/gradle-8.10.2-*

Then the build cache, which only costs the next build some speed:

rm -rf ~/.gradle/caches/build-cache-1

And if you want everything back, the whole cache and every wrapper download:

rm -rf ~/.gradle/caches ~/.gradle/wrapper/dists

A common suggestion for a broken dependency is --refresh-dependencies. It doesn't free any space. According to Gradle's documentation, it makes Gradle ignore cached entries and resolve again against your repositories, but it still checks the files it has before downloading anything. Use it when the cache is wrong, and delete when the cache is big.

Both are safe to delete; the next build recreates them. In a project you work on, ./gradlew clean removes the build/ folders. For old projects you no longer open, list every Gradle build/ folder with its size. This finds only folders that sit next to a build.gradle or build.gradle.kts, so unrelated folders called build stay out:

find ~/code -name build -type d -prune \( -exec test -e '{}/../build.gradle' \; \
  -o -exec test -e '{}/../build.gradle.kts' \; \) -exec du -sh {} +

The same idea applies to node_modules and other dependency folders; see deleting node_modules.

Gradle is only part of it. The Android SDK, by default in ~/Library/Android/sdk, keeps platforms, build tools, the emulator and, usually the heaviest, emulator system images:

du -sh ~/Library/Android/sdk/* | sort -h
du -sh ~/Library/Android/sdk/system-images/*/*/*

A system image comes back by downloading it again, but every emulator built on it stops working until you do. Each emulator names its image in its config.ini, as a line like image.sysdir.1=system-images/android-34/…. Remove images in Android Studio's SDK Manager (Tools → SDK Manager): clear the checkbox next to the package and click Apply. From Terminal, the sdkmanager tool in the SDK's command-line tools does the same. Its package IDs are the folder path with semicolons:

sdkmanager --list
sdkmanager --uninstall "system-images;android-34;google_apis;arm64-v8a"

Google now marks sdkmanager as deprecated in favor of the Android CLI, whose android sdk remove does the same job.

Emulators (AVDs)

The emulators themselves live in ~/.android/avd: a name.avd folder and a name.ini file for each. The folder holds the emulator's disk, with every app you installed, its data, your logins and any snapshots. That is state, not cache: deleting it gives you a factory-new device. On the Mac this guide was checked on, one emulator's user data took 1.2 GB.

Delete emulators you don't need in Device Manager (Menu → Delete), or keep the emulator and choose Wipe Data to reset it. From Terminal, list the emulators and delete one by the name the list shows:

avdmanager list avd
avdmanager delete avd -n <name>

Android Studio's own folders

Every Android Studio version gets its own set of folders, as Google documents. For version 2025.2.2, they are:

• ~/Library/Caches/Google/AndroidStudio2025.2.2 — system files: indexes and caches.
• ~/Library/Logs/Google/AndroidStudio2025.2.2 — logs.
• ~/Library/Application Support/Google/AndroidStudio2025.2.2 — your settings and plugins.

After an upgrade, the folders of the old version stay. With Android Studio closed, the caches and logs of a version you no longer run are safe to delete. Keep the Application Support folder of the version you use: it holds your settings.

Maven keeps its local repository in ~/.m2/repository. Most of it is downloaded, but anything you built with mvn install lives only there until you build it again. To drop and re-download a single project's dependencies, run mvn dependency:purge-local-repository in that project.

IntelliJ IDEA and other JetBrains IDEs keep caches and indexes in ~/Library/Caches/JetBrains/<product><version>, such as IntelliJIdea2024.2. According to JetBrains, a new major version deletes the caches and logs of older versions that weren't updated for 180 days, and Help → Delete Leftover IDE Directories removes the rest. Their settings folders stay until you remove them.

Heap dumps are easy to miss. When a JVM started with -XX:+HeapDumpOnOutOfMemoryError runs out of memory, it writes its whole heap to a file called java_pid<pid>.hprof in its working directory, unless -XX:HeapDumpPath points elsewhere, and each one is about as large as the heap was. Unless you are investigating that crash, they are safe to delete. This finds them, though walking your whole home folder takes a while and macOS may ask for access to some folders:

find ~ -name 'java_pid*.hprof' -size +10M -exec ls -lh {} + 2>/dev/null

Specula measures ~/.gradle/caches, the wrapper distributions, Android system images, emulators, the Maven repository and JetBrains caches in its Cleanup → Tools list, each marked as regenerable, app data or your data, so you can see which ones cost a download and which ones hold state. Its Old versions page finds versions sitting next to each other, such as gradle-8.9-bin beside a newer distribution or IntelliJIdea2024.2 beside a newer IDE folder.

In the one-click Clean Up plan, older Gradle versions, Android system images and JetBrains caches are offered but start unchecked, because they cost a download or a running IDE's cache. For Gradle, only versions older than the newest one go, so the newest always stays. Heap dumps (java_pid*.hprof, java_error_in_*.hprof, from 10 MB) are checked by default, but never from personal folders like Documents, and only while they are unchanged since the scan. Gradle build/ and .gradle/ folders appear under project artifacts, with when each project was last touched; those of projects nobody touched for 14 days are checked by default. Emulators and the Maven repository are never part of the plan. Nothing is deleted until you confirm.

If the space went somewhere else entirely, start with what to check when your disk is almost full, or see what Specula does as a Mac cleaner for developers.