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
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.
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