Android Studio

Android Studio, Gradle, and emulator images: the Android storage trio

Android development tooling stores dependencies, SDK components, and emulator images in separate locations. Together, they can become one of the largest hidden storage sources on macOS.

Updated:

Read time: 7 min

Why this silently grows

Gradle caches every dependency graph, Android SDK directories keep historical build tools and platforms, and each emulator image can occupy multiple gigabytes. If your team tests across API levels and device profiles, accumulation is fast.

How Free Mac Space finds it

Free Mac Space highlights Android tooling paths including ~/.gradle/caches, ~/.android, ~/Library/Android/sdk, and Android Studio cache/state folders in ~/Library/Caches/Google and ~/Library/Application Support/Google. This reveals which layer is consuming the most storage right now.

How cleanup is handled

Use a review-first flow: start with oversized Gradle caches and obsolete emulator images, then verify what SDK versions are still required before selecting additional cleanup targets.

Safety boundary

Removing the wrong SDK or emulator files can break active build pipelines. Keep versions tied to current CI and release branches before deleting historical assets.

Paths covered in Free Mac Space

  • ~/.gradle/caches
  • ~/.android
  • ~/Library/Android/sdk
  • ~/Library/Caches/Google/AndroidStudio*
  • ~/Library/Application Support/Google/AndroidStudio*

Recommended monthly check

  • Clean stale Gradle caches after major dependency upgrades.
  • Remove emulator images for API levels you no longer test.
  • Confirm builds still pass, then export a report for team baseline tracking.

Step-by-step workflow

  1. 1. Identify why Android Studio storage keeps growing

    Gradle caches every dependency graph, Android SDK directories keep historical build tools and platforms, and each emulator image can occupy multiple gigabytes. If your team tests across API levels and device profiles, accumulation is fast.

  2. 2. Inspect the highest-impact paths first

    Free Mac Space highlights Android tooling paths including ~/.gradle/caches, ~/.android, ~/Library/Android/sdk, and Android Studio cache/state folders in ~/Library/Caches/Google and ~/Library/Application Support/Google. This reveals which layer is consuming the most storage right now. Priority paths: ~/.gradle/caches, ~/.android, ~/Library/Android/sdk, ~/Library/Caches/Google/AndroidStudio*, ~/Library/Application Support/Google/AndroidStudio*.

  3. 3. Confirm the safety boundary before acting

    Removing the wrong SDK or emulator files can break active build pipelines. Keep versions tied to current CI and release branches before deleting historical assets.

  4. 4. Apply a review-first cleanup workflow

    Use a review-first flow: start with oversized Gradle caches and obsolete emulator images, then verify what SDK versions are still required before selecting additional cleanup targets.

  5. 5. Monthly validation step 1

    Clean stale Gradle caches after major dependency upgrades.

  6. 6. Monthly validation step 2

    Remove emulator images for API levels you no longer test.

  7. 7. Monthly validation step 3

    Confirm builds still pass, then export a report for team baseline tracking.

Frequently asked questions

  • What hidden storage sources are covered for Android Studio?

    Primary sources include Gradle dependency cache, Android SDK packages, AVD emulator disk images. Gradle caches every dependency graph, Android SDK directories keep historical build tools and platforms, and each emulator image can occupy multiple gigabytes. If your team tests across API levels and device profiles, accumulation is fast.

  • Which macOS paths should I inspect first?

    Start with: ~/.gradle/caches, ~/.android, ~/Library/Android/sdk, ~/Library/Caches/Google/AndroidStudio*, ~/Library/Application Support/Google/AndroidStudio*. Free Mac Space highlights Android tooling paths including ~/.gradle/caches, ~/.android, ~/Library/Android/sdk, and Android Studio cache/state folders in ~/Library/Caches/Google and ~/Library/Application Support/Google. This reveals which layer is consuming the most storage right now.

  • How can I reduce this storage safely?

    Use a review-first flow: start with oversized Gradle caches and obsolete emulator images, then verify what SDK versions are still required before selecting additional cleanup targets. Removing the wrong SDK or emulator files can break active build pipelines. Keep versions tied to current CI and release branches before deleting historical assets.

  • What should the monthly review checklist look like?

    Clean stale Gradle caches after major dependency upgrades. Remove emulator images for API levels you no longer test. Confirm builds still pass, then export a report for team baseline tracking.

Continue in the matching solution

If you're ready to act, continue in "npm / pnpm / Yarn / Bun cache cleanup" with a step-by-step workflow.

Open matching solution page

More hidden storage cases

Xcode

Xcode DerivedData and DeviceSupport: the classic hidden giant

Xcode can quietly keep tens of gigabytes in build artifacts and simulator/device support files. This post explains where it grows and how to clean without breaking active projects.

Read article

Docker

Docker Desktop VM disk: why it keeps growing after projects end

Docker images, layers, and build cache are stored inside Docker-managed directories and VM disk files. They can grow fast and stay invisible to normal Finder checks.

Read article

Homebrew

Homebrew cache folders: small installs, surprisingly large history

Homebrew keeps download and metadata caches that can survive across upgrades. They are safe cleanup candidates when they become oversized.

Read article