Programming

Possible to change where Android Virtual Devices are saved

19 September 2026 · 9 min read

Possible to change where Android Virtual Devices are saved

Android Virtual Devices (AVDs) are essential tools for Android app developers, providing emulated environments to test apps on various Android versions and hardware configurations without needing physical devices. However, the default location where these AVDs are stored can quickly consume valuable space on your primary drive, especially if you’re working on multiple projects or require numerous AVDs for comprehensive testing. Many developers find themselves asking: Is it possible to change where Android Virtual Devices are saved? The good news is yes, it absolutely is! This article will guide you through the process, explaining why you might want to relocate your AVDs, the steps involved, and potential issues you might encounter, ensuring you can manage your development environment efficiently and keep your primary drive clutter-free.

Why Change the AVD Storage Location?

The default location for AVD storage is typically within your user profile directory (e.g., C:\Users\[YourUsername]\.android\avd on Windows or ~/.android/avd on Linux/macOS). This can become problematic for several reasons. Firstly, your primary drive, often an SSD for faster performance, might have limited storage capacity. Filling it up with AVDs can slow down your system. Secondly, separating your AVDs from your system drive can make backups and system maintenance easier. Imagine needing to reformat your primary drive – having your AVDs on a separate partition or drive means you won’t have to recreate them from scratch. Finally, if you’re working in a team environment, storing AVD images on a shared network drive can facilitate collaboration and consistency across different developer workstations.

Relocating your AVDs can also improve performance in certain scenarios. If you have a secondary drive that’s faster than your primary drive (or less heavily utilized), moving your AVDs there might result in quicker emulator startup times and smoother operation. According to a study by Android Authority, developers spend an average of 18% of their development time waiting for emulators to boot and run applications [Android Authority]. Optimizing emulator performance, even slightly, can significantly increase overall productivity. By changing the AVD storage location, you’re taking a proactive step towards a more efficient and organized development workflow.

Here are some key advantages of changing the AVD storage location:

  • Free up space on your primary drive.
  • Simplify backups and system maintenance.
  • Potentially improve emulator performance.
  • Facilitate team collaboration by using shared storage.

How to Change the AVD Storage Location

The process of changing the AVD storage location involves modifying an environment variable that Android Studio uses to determine where to store AVD files. This method is relatively straightforward and can be accomplished in a few simple steps. It’s crucial to follow these steps carefully to avoid any issues with your AVD configurations. The following steps will guide you on how to relocate your AVDs:

  1. Identify the New Location: Choose a new directory where you want to store your AVDs. This could be on a different partition, a separate drive, or even a network share. Ensure that you have sufficient read/write permissions to this directory.
  2. Set the ANDROID_AVD_HOME Environment Variable: This is the key step. The ANDROID_AVD_HOME environment variable tells the Android emulator where to look for AVD configuration files and disk images.
  • Windows: Go to System Properties (search for “environment variables” in the Start Menu). Click on “Environment Variables.” Under “System variables,” click “New…” Enter ANDROID_AVD_HOME as the variable name and the full path to your new AVD directory as the variable value.
  • macOS/Linux: Open your shell configuration file (e.g., .bashrc, .zshrc). Add the following line: export ANDROID_AVD_HOME=/path/to/your/new/avd/directory. Remember to replace /path/to/your/new/avd/directory with the actual path. Then, source the file (e.g., source ~/.zshrc).
  1. Move Existing AVDs (Optional): If you have existing AVDs that you want to move to the new location, manually copy the contents of your old AVD directory (~/.android/avd or C:\Users\[YourUsername]\.android\avd) to the new directory you specified in the ANDROID_AVD_HOME variable.
  2. Verify the Change: Restart Android Studio and create a new AVD. Check the new AVD directory to confirm that the files are being created in the correct location. You can also check the AVD Manager in Android Studio to see if it correctly lists your existing (moved) AVDs. Featured Snippet: To change the storage location of Android Virtual Devices, you need to set the ANDROID_AVD_HOME environment variable. This variable tells the Android emulator where to look for AVD configuration files and disk images. On Windows, you can set this variable in System Properties. On macOS/Linux, you can add it to your shell configuration file (e.g., .bashrc, .zshrc). After setting the variable, you may need to move your existing AVDs to the new location manually.

Potential Issues and Troubleshooting

While the process of changing the AVD storage location is generally straightforward, you might encounter some issues. One common problem is incorrect path configuration. Double-check that the path you specified in the ANDROID_AVD_HOME environment variable is correct and that you have the necessary permissions to access that directory. Another issue can arise if you forget to move existing AVDs after changing the environment variable. This will result in Android Studio not being able to find your existing AVDs. Make sure to copy the contents of your old AVD directory to the new location. Furthermore, conflicting environment variables can sometimes cause problems. Ensure that there are no other environment variables related to Android SDK paths that might be interfering with the ANDROID_AVD_HOME variable. For example, using the wrong path for ANDROID_SDK_ROOT can cause unexpected behavior.

If you’re still experiencing issues, try invalidating caches and restarting Android Studio. This can sometimes resolve conflicts or inconsistencies in the IDE’s configuration. Additionally, check the Android Studio logs for any error messages related to AVD loading or path resolution. These logs can provide valuable clues about the root cause of the problem. Finally, consider consulting online forums and communities, such as Stack Overflow, for solutions to common AVD-related issues. Many developers have encountered similar problems and shared their solutions online. Remember to clearly describe your problem and the steps you’ve already taken when seeking help from online communities. According to Stack Overflow data, questions related to Android AVD configuration often receive helpful answers within a few hours [Stack Overflow].

Here are some troubleshooting tips:

  • Double-check the ANDROID_AVD_HOME path for typos and correct permissions.
  • Ensure you’ve moved existing AVDs to the new location.
  • Invalidate caches and restart Android Studio.
  • Check Android Studio logs for error messages.
  • Consult online forums for solutions.

Alternative Methods and Considerations

While setting the ANDROID_AVD_HOME environment variable is the most common and recommended method, there are alternative approaches you could consider, although they might be less convenient or less reliable. One option is to use symbolic links (symlinks). A symlink is a file system object that points to another file or directory. You could create a symlink from the default AVD directory (~/.android/avd or C:\Users\[YourUsername]\.android\avd) to your desired storage location. However, symlinks can sometimes be problematic, especially on Windows, due to permission issues or compatibility with certain file systems. Another approach is to manually edit the AVD configuration files (.ini files) to point to the new location of the AVD disk images. This is generally not recommended, as it’s error-prone and can lead to inconsistencies if not done carefully. It’s best to stick with the ANDROID_AVD_HOME environment variable method, as it’s the most officially supported and reliable approach.

Another important consideration is the type of storage you’re using for your AVDs. While using a network share can be convenient for team collaboration, it’s important to ensure that the network connection is stable and that the network share provides sufficient performance. Running AVDs over a slow or unreliable network can lead to significant performance degradation and even data corruption. If you’re using a network share, consider using a dedicated network drive with high bandwidth and low latency. Also, regularly back up your AVDs to prevent data loss in case of network issues or storage failures. Always test your AVD configurations thoroughly after changing the storage location to ensure that everything is working as expected. Using cloud storage for your AVDs is generally not recommended due to latency issues. According to Google’s developer documentation, using local storage is always preferable for optimal AVD performance [Android Developers].

Infographic here
FAQ About Changing AVD Storage ------------------------------
**Q: Will changing the AVD storage location affect the performance of my emulators?**
A: It depends. If you move your AVDs to a faster drive, you might see improved performance. However, if you move them to a slower drive or a network share with high latency, you could experience performance degradation.
**Q: Do I need to reinstall Android Studio after changing the ANDROID\_AVD\_HOME variable?**
A: No, you don't need to reinstall Android Studio. Simply restart Android Studio after setting the environment variable for the changes to take effect.
**Q: Can I have different AVDs stored in different locations?**
A: While technically possible by manually editing AVD configuration files, it's generally not recommended. Using a single, consistent location for all your AVDs simplifies management and reduces the risk of errors.
**Q: What happens if I delete the ANDROID\_AVD\_HOME variable?**
A: If you delete the ANDROID\_AVD\_HOME variable, Android Studio will revert to using the default AVD storage location in your user profile directory (~/.android/avd or C:\\Users\\\[YourUsername\]\\.android\\avd).
In summary, relocating your Android Virtual Devices is a valuable strategy for optimizing your development environment, freeing up primary drive space, and improving organization. By carefully following the steps outlined in this article and addressing potential issues proactively, you can successfully change the AVD storage location and enjoy a more efficient and streamlined Android development experience. Don't let a cluttered drive hinder your productivity – take control of your AVD storage today!

Now that you know how to manage your AVD storage, why not explore other ways to optimize your Android development workflow? Check out our article on debugging Android applications or learn about the latest features in Android Studio here.

Question & Answer :
I’ve set up the Android SDK and Eclipse on my machine running Windows XP and AVDs (Android Virtual Devices) are saved to “Documents and Settings\user\.android” by default. Is there any way to change this behavior? I have all of the other components saved in a directory on a separate partition and would like everything to be consolidated. Obviously not a huge deal but does anyone here know a workaround for this?

Add a new user environment variable (Windows 7):

  1. Start Menu > Control Panel > System > Advanced System Settings (on the left) > Environment Variables

  2. Add a new user variable (at the top) that points your home user directory:> Variable name: ANDROID_SDK_HOME

    Variable value: a path to a directory of your choice

AVD Manager will use this directory to save its .android directory into it.

For those who may be interested, I blogged about my first foray into Android development…
Android “Hello World”: a Tale of Woe

Alternatively, you can use the Rapid Environment Editor to set the environment variables.