Language toolchains & SDKs

How to Delete Android Emulator AVD Files and Reclaim 10GB on macOS

If you do any Android development on a Mac, your disk is almost certainly carrying several gigabytes of virtual device snapshots and system images you no longer need. Knowing how to delete Android AVD files correctly — without accidentally breaking a project or wiping a device configuration you still use — can recover anywhere from 5 GB to well over 20 GB depending on how many emulators you have created over the years. This guide covers every folder involved, which files are safe to remove, and how to do the cleanup manually or with the Android tools that ship with the SDK.

Where Android Studio Stores AVD Files on macOS

Android Virtual Device files live in a small number of well-known locations. Unlike Xcode, which scatters data across ~/Library/Developer, the Android toolchain keeps almost everything inside your home directory under two root folders.

  • ~/.android/avd/ — the primary AVD home. Each virtual device is represented by a .ini pointer file and a matching .avd directory containing the disk image, userdata snapshot, config, and hardware profile.
  • ~/Library/Android/sdk/system-images/ — the system image packages downloaded via the SDK Manager. These are separate from the AVD instances but are by far the largest contributors to disk usage.
  • ~/.android/cache/ — cached package metadata and update manifests.
  • ~/Library/Caches/Google/AndroidStudio*/ — IDE caches including build outputs and indexing data for Android Studio itself.

On Apple Silicon Macs running macOS Sequoia or Tahoe, the paths are identical — the ~ home expands to /Users/yourname on both architectures. If you installed the SDK to a custom location, check Android Studio → Settings → Android SDK → Android SDK Location to find it.

How Much Space Are These Files Actually Using?

Before deleting anything, run a quick audit from Terminal so you know what you are dealing with:

du -sh ~/.android/avd/
du -sh ~/Library/Android/sdk/system-images/
du -sh ~/Library/Caches/Google/

The table below shows typical sizes for common components so you can prioritise what to tackle first.

Location What it contains Typical size Safe to delete?
~/.android/avd/*.avd/ Emulator disk image + userdata + snapshots 2–8 GB per device Yes — recreate AVD from SDK Manager
~/Library/Android/sdk/system-images/ Downloaded OS images (x86_64, arm64-v8a) 1–4 GB per API level Yes — re-download via SDK Manager
~/.android/avd/*.avd/snapshots/ Saved emulator state snapshots 500 MB–2 GB per snapshot Yes — emulator restarts cold boot
~/Library/Caches/Google/AndroidStudio*/ IDE index, build cache 1–3 GB Yes — IDE rebuilds on next launch
~/.android/cache/ SDK package metadata 50–200 MB Yes

How to Delete AVD Files Using Android Studio's Device Manager

The safest and most supported method is to remove AVDs through the built-in Device Manager. This ensures that both the .avd directory and its matching .ini pointer file are removed together — leaving orphaned .ini files behind is a common mistake when deleting manually.

  1. Open Android Studio and go to View → Tool Windows → Device Manager (or click the Device Manager icon in the right sidebar).
  2. Find the virtual device you want to remove. Hover over it to reveal the action icons.
  3. Click the three-dot overflow menu on the right and choose Delete.
  4. Confirm the deletion in the dialog that appears.
  5. Repeat for each AVD you no longer need.

After deleting AVDs, open Settings → Android SDK → SDK Platforms, switch to the SDK Tools tab, and use the SDK Manager to uninstall system images for API levels you no longer target. Each image removed here reclaims 1–4 GB depending on the ABI variant.

Deleting AVD Files Manually from Terminal

If Android Studio is not installed (for example, you only use the command-line tools), you can delete AVDs directly from the shell. Use avdmanager when available — it handles both the directory and the pointer file correctly:

# List all AVDs
avdmanager list avd

# Delete a specific AVD by name
avdmanager delete avd -n Pixel_9_API_35

If avdmanager is not on your PATH, add the SDK tools directory first:

export PATH="$PATH:$HOME/Library/Android/sdk/cmdline-tools/latest/bin"

To delete manually without the tool, remove both the .ini file and the corresponding .avd folder:

# Replace Pixel_9_API_35 with your actual AVD name
rm ~/.android/avd/Pixel_9_API_35.ini
rm -rf ~/.android/avd/Pixel_9_API_35.avd

Double-check the name by running ls ~/.android/avd/ first — the .ini and .avd entries must match exactly.

Removing Snapshots Without Deleting the Whole AVD

Snapshots let the emulator resume instantly, but they accumulate quickly — each one can consume 500 MB to 2 GB. If you want to keep the AVD configuration but reclaim snapshot space, delete just the snapshots subdirectory:

rm -rf ~/.android/avd/Pixel_9_API_35.avd/snapshots/

The emulator will fall back to a cold boot the next time it starts. You can also manage snapshots from inside the running emulator: click the three-dot icon in the emulator toolbar, go to Snapshots, and delete individual entries from the UI.

Clearing Android Studio IDE Caches

The IDE itself accumulates caches under ~/Library/Caches/Google/. These are completely safe to remove — Android Studio recreates them on next launch, though the first startup after clearing will be slower as it re-indexes your projects.

# Remove all Android Studio cache folders (adjust the glob for your version)
rm -rf ~/Library/Caches/Google/AndroidStudio*/

You can also trigger this from inside Android Studio via File → Invalidate Caches → Invalidate and Restart, which is the recommended approach if the IDE is currently open.

If your Mac is also an iOS development machine, you may have a similar accumulation under ~/Library/Developer/Xcode/DerivedData/. That folder is covered in detail in our post on why Xcode takes up so much space. The principle is the same: cached build products that can be regenerated on demand.

Removing Unused SDK System Images

System images are downloaded separately from AVD instances. If you deleted an AVD but never uninstalled its system image, the image directory still occupies disk space under ~/Library/Android/sdk/system-images/. The directory structure looks like this:

~/Library/Android/sdk/system-images/
  android-35/
    google_apis_playstore/
      arm64-v8a/      ← ~1.5 GB
      x86_64/         ← ~1.5 GB
  android-33/
    google_apis/
      arm64-v8a/      ← ~1.2 GB

On Apple Silicon Macs you only need the arm64-v8a ABI for native performance — the x86_64 images require Rosetta 2 translation and run slower. On Intel Macs it is the reverse. Removing the ABI variant you do not use can free an additional 1–2 GB per API level.

Use the SDK Manager to uninstall images cleanly: go to Settings → Android SDK → SDK Platforms, check Show Package Details, and deselect the image variants you no longer need, then click Apply.

Keeping Things Under Control Going Forward

A few habits prevent the disk from ballooning again over the next year:

  • Create AVDs with the minimum storage size your test requires. The default 2 GB internal storage can often be reduced to 800 MB for most unit and UI tests.
  • Turn off automatic snapshot saving unless you specifically need resume-on-relaunch: in the AVD configuration, set Emulator Startup → Cold Boot.
  • After a major API level release, uninstall old system images for API levels you no longer target before downloading the new one.
  • If you work across multiple toolchains — Node modules, Gradle caches, Cargo build artifacts — the folders compound quickly. A tool like Crumb can audit all of these at once and show what is safe before you delete, which is helpful when you are not sure which caches belong to which project.

For a broader look at what is consuming your startup disk, the guide on what is taking up space on your Mac walks through the full picture beyond developer tools alone.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

Is it safe to delete AVD files on macOS?
Yes. Deleting an AVD removes the virtual device and its disk image, but it does not affect your source code, project files, or the Android SDK itself. You can recreate the AVD at any time from the Device Manager using the same system image, though any app data or settings stored inside the emulator will be lost.
Where exactly are AVD files stored on a Mac?
The main AVD directory is ~/.android/avd/ — each device has a .ini file and a matching .avd folder there. System images are stored separately under ~/Library/Android/sdk/system-images/, and IDE caches live in ~/Library/Caches/Google/AndroidStudio*/.
Will deleting AVD files affect my Android Studio projects?
No. AVD files are emulator instances, not project files. Your source code, Gradle build files, and project settings are stored in your project directories and are completely unaffected. You will just need to recreate or reconfigure the virtual device before running the emulator again.
How much space can I realistically recover?
It varies widely, but developers who have been using Android Studio for a year or more typically recover between 5 GB and 20 GB. Each AVD instance uses 2–8 GB, each system image 1–4 GB, and IDE caches another 1–3 GB. Running du -sh ~/.android/avd/ and du -sh ~/Library/Android/sdk/system-images/ before you start gives you a concrete number.
Can I delete system images without deleting the AVD?
You can, but the AVD will fail to launch until you re-download the matching system image. It is best to delete the AVD first, then uninstall the system image via the SDK Manager. If you want to keep the AVD runnable, leave the system image in place.