Android Virtual Devices and SCM: Ensure All Team Members Develop for the Same Platform

Experience is what you get when you don’t get what you want.

– Dan Standford

I set out to solve the problem of different developers and testers on the same team mistakenly writing their software on different platforms. I thought we needed a way to add Android Virtual Devices (AVD) to source control so developers and testers can assure they’re writing and testing on the same device.

I can report that I have increased my experience in this area.

I haven’t gotten to where I had hoped to get, but the experience was enlightening (no, really!) and there are potential solutions on the horizon.

You probably know that an AVD is a configuration or description that is sent to the Emulator when you’re testing your Android app on a host system. The Emulator uses an AVD so it can pretend it’s the phone or device you’re writing your code for. AVDs are easy to create using the Android command line tool or via the Eclipse integration that comes with the Android SDK.

Here’s the problem…

AVDs appear simple, but there are a number of different options and configurations that can be applied to them. No doubt the number of options will grow over time. So it becomes important to assure that a developer is testing on an approved or relevant configuration, and the integration testers are using the same configuration – the same AVD – to test the team’s builds. If every developer is creating and managing their own AVDs, there’s a higher chance that the AVD used for integration testing will not match the AVD that one or more developers are using. Hilarity ensues as everyone shouts “It works on my machine!”

So we have unnecessary integration errors that can occur because developers and testers can use different settings in their AVDs. In other words, team members could be developing and testing on different platforms.

Unfortunately, Google doesn’t set up AVDs to be managed like other artifacts (such as source code) in an Eclipse project. By default, AVDs are placed a directory called


on Windows 7 (and different locations on other systems). This ties AVDs closely to an individual’s development machine instead of allowing everyone to use the same AVD. In addition, each AVD has a .ini file that describes the location of the AVD to the SDK/AVD Manager. That .ini file must be in the .android directory or it can’t be found by the SDK/AVD Manager.

You can use the

android move avd -p

option to change the location of an AVD, but that only puts it somewhere else on the same system. And it doesn’t change the location of the .ini file.

Placing the AVD on a shared network directory is apparently not recommend by Google (the documentation is ambiguous), so that’s not a good option either.

This is ugly. A developer can’t easily share an AVD with another developer or tester. The result is that everyone’s AVDs ends up being be built locally. It’s repetitive manual effort that takes time and introduces errors into development. So I set out to create a perfect world where Android developers and testers could share the same AVDs via SCM.

Silly me.

As I was checking my first AVD into an SCM repository, I noticed that it was taking longer than expected. Much longer. Then I saw the 60MB binary file that my repository was choking on. This was the system image for the AVD. I started to think of my SCM administrator screaming at me for eating up gobs of disk space. I imagined the ridicule and disdain I would receive from my colleagues. I canceled the upload.

Hey, maybe Google has a reason for keeping those AVDs out of source control after all!

Here’s the deeper problem…

An SCM system is designed to manage parallel development that involves many changes performed on lots of small files, usually text files. I was thinking of our AVDs like source code, but they’re not. Instead, we want to share a common binary asset that changes infrequently. An AVD isn’t part of a build or a deliverable like source code is. It’s part of our development environment. And it should be shared across workspaces, like developers and testers share workspace configurations and compiler options.

So now we’ve identified the problem but we’re still stuck with it: developers and testers on the same team can mistakenly write and test Android software on different platforms. The problem doesn’t go away just because I picked the wrong tool.

One way to address this would probably involve using the Rational Asset Manager, which is designed to manage much larger assets than any SCM is designed for. But that’s a blog for another day. Now I need to clear my head and go code something.

– Jim Ruehlin


This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

3 Responses to Android Virtual Devices and SCM: Ensure All Team Members Develop for the Same Platform

  1. dtoczala says:

    I liked this. It highlights the core issue, that environmental “things” like SDKs, AVDs, and JVMs need to be managed with something other than an SCM system. SCM systems are built for source code, not build artifacts.

  2. Pingback: 2010 in review | JazzPractices

  3. Steffen says:

    Thanks for this hints. The AVD Location”Function” is actually a little strange problem, especially why i use the android move avd command on windows 7 and get a new problem if i would move the image to a another driveletter: “”Error: Failed to move …”
    and after this i find this …:
    “Current issue here is ‘android move avd’ fails between different drive letters.”

    Greetings Steffen

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s