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.inipointer file and a matching.avddirectory 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.
- Open Android Studio and go to View → Tool Windows → Device Manager (or click the Device Manager icon in the right sidebar).
- Find the virtual device you want to remove. Hover over it to reveal the action icons.
- Click the three-dot overflow menu on the right and choose Delete.
- Confirm the deletion in the dialog that appears.
- 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.