How to Export and Import Android Virtual Devices

Over the last couple of weeks, I have been testing my Android app on different devices. That work is going well. In this note, I’d like to share a couple of things that came out as side effects of that work, including:

1. How to move Android virtual device (AVD)  files from an Android Emulator  to another machine.
2. The set of AVD definitions that I found useful in checking an app on different screen sizes and screen densities.

Knowing how to move AVD files is important for a couple of reasons: (a) if you ever switch machines or do a complete reinstall of your Android environment, it would be good if you could reuse old device definitions rather than having to recreate them; (b) If you are working on a team, it saves a lot of time if there is a shared set of devices that everyone in the team is testing against.

How To Move AVD Files

There are a few things you need to understand about Android virtual device (AVD) files. The first is what they are. Basically, they are files that hold the description of an Android device and what’s on that device in the Emulator environment. If you need more information, start with the Android Developers note on “Managing Virtual Devices“.

Whether you are working alone or on a team, sooner or later you will want to know how to move your AVD files from one machine to another. Here’s what I have learned about that task.

Where do AVD definitions reside on your disk?

To find your avd folder on you machine, check your user directory. For me, with user name “blahti”, those locations are:

• Windows 7: \users\blahti\.android
• Windows XP: C:\Documents and Settings\blahti\.android\ on Windows XP
• Linux/Mac: ~/.android

Here’s a tip for new Mac users (like me). In the Finder window, you have to use the “Go To Folder” item on the “Go” menu to get to “~/.android”.

Steps for moving

Here are the basic steps:

1. Go to the .android folder and pick the avd you want to export.
2. Compress the device.avd folder and the device.ini file.
   (Replace “device” with the name of the device you want to copy. For example: Evo4g.avd, Evo4g.ini.)
3. Copy the compressed files to the new location, usually on a different machine.
4. Extract the files and place them in the user’s .android folder.
5. Edit the ini file and make corrections, as needed:
   (a) user name could be different; (b) change slash in path to Windows or Unix slash.

Example ini file contents on a Mac:

target=android-8
path=/Users/bill/.android/avd/Evo4G.avd

Example ini file contents on Windows 7:

target=android-8
path=C:\Users\blahti\.android\avd\Evo4G.avd

Example ini file contents on Windows XP:

target=android-8
path=C:\Documents and Settings\blahti\.android\avd\Evo4G.avd

Start the AVD Manager under Eclipse and be sure the files are readable. See Figure 1 below.

Figure 1 – Start the AVD Manager in Eclipse

If there is an error, a red X is displayed, as in Figure 2. Highlight the item, and see if the “Repair” button is enabled. Click “Repair” if it is. Or click the “Details” button for more information. In most cases, it will be something wrong with the path in the ini file you just edited. .Always check that first. After you edit a file, click the “Refresh” button to see if your correction worked. Figure 3 shows that all corrections have been accepted.

Figure 2 – AVD Manager shows errors

Figure 3 – AVD Manager shows corrections

To use the new AVD definitions, run the ADB Device Manager. You will need two pieces of information: (a) the diagonal measure for your computer’s screen; (b) the actual size of the screen for the Android phone or device.
Click “Start…” and fill in the diagonal screen size.

Figure 4 – Start a Device from the AVD Manager

Here are a few values for diagonal size (the “d” value). If you are testing with other devices, a Google search for your phone name with the word “specs” usually gets you what you want.

HTC Evo 480 x 800, LCD 217, d 4.3
Motorola Droid 3 – 540 x 960, LCD 275, d 4
Motorola Droid – 480 x 854, LCD 265, d 3.7
NexusOne – 480 x 800, LCD 252, d 3.7
LG Optimus S – 320 x 480, LCD 180, d 3.2
HTC Tattoo, 240 x 320, LCD 143, 2.8  — small screen, low density

My Set of Android Virtual Devices For Testing

Here is the set of virtual device definitions that I have been using in my testing. The set includes large and small screen sizes and low, medium, and high density screens.  I have not tried tablets yet.

To get the zip files for these AVD definitions, go to my shared avd folder in Google Docs. When you get there, do not click on the zip files there. Instead right-click with the mouse button (control-click on a Mac). That gets you to a menu with a “Download” link on it.

To use them, just download the zip file and move the files to the right place, as described in the first section of this note. Each of these comes with a Dashboard UI Demo app already installed.  To give you an idea of what these different devices look like, here’s a screenshot of the six devices running a demo program. Basically, it looks reasonable except on the small screen of the HTC Tattoo.

Figure 5 – Demo program running on different virtual devices

The AVD files encode the device information shown in the previous section. If you add more device definitions and have to calculate the LCD value, here is the formula:

LCD = sqrt (x^2 + y^2) / d

References

I’d like to thank once again the Android community, and particularly the people who support the Android Developers website, for their willingness to share information and help one another. Here are the references I found most useful for this work:

Managing Virtual Devices – an intro article on the Android Developers website. It describes what an AVD file is, what it contains, and how it’s used in the Android Emulator.

Supporting Multiple Screens – a good place to start to understand how to deal with the different screen sizes and densities. Once you start testing on multiple devices, you’re likely to discover that you have problems. This article and the next one are essential references.

Providing Resources – an article on how you structure your application to handle different devices.

Question at StackOverflow about testing on multiple devices –  I liked the suggestions about which set of devices to choose for a representative set, given the current statistics on actual devices in use.

Screen Sizes and Densities – current data on what devices are in use. This was mentioned in the Stack Overflow note above.