learned a few things about Ubuntu and VirtualBox

My main goal tonight was to get through the different layout samples to get a better grasp on layout in Android. Unfortunately, work leaked so I had to do some Ubuntu and VirtualBox configuration. Turned out to be pretty interesting and reminded me how much I like Ubuntu.

I set up a VM instance - this was fine, went as normal. The new part here was that I wanted to use VBox snapshots. Once the VM was prepared, I exported the config and HD image to put on our filer system as part of my usual process. After the traditional style backup was done, I tried creating a Snapshot of the VM. Assuming the snapshots work, they're might simple: you get to give each snapshot a name and description. There are options to delete snapshots, remove current config, and a few other things.

As part of the preparation of the VM, I had to set up an application launcher in the VM image. I've done launchers before but this was a little new because I wanted the launcher on the desktop but the actual scripts within the home directory structure. The problem I hit was that the main script used relative paths to reference other scripts. The solution to my issue was here. I had assumed "cd {abs directory}; ./{script}" but it has to be 'sh -c "cd {abs directory} && ./{script}"'. Huh.

I set both the host and guest instances to perform Auto-Login to be easy for the line setup. In the host, I added a Startup Application to auto-start my guest. This reminds me how much I like VirtualBox: VBoxManage has lots of different options that I've found useful. In this case, I do 'Command: VBoxManage startvm "gateway configuration station"'. Since the VM is configured for full-screen, I ultimately end up at the desired UI after powering on the physical box. Good stuff!

Back on the Android stuff, I was pleased there as well: started bumping into the design surfaces in ADT and they look helpful, used the Debug perspective with an Android app running in the emulator (and breakpoints worked :)), and Android will deal with about anything for the icons.

first Android app

Google provides great tools to get started. The guys at work are Maven fanboys so they referred to a couple Maven-Android projects to use. I followed their lead and took the time to set up Masa but that was a total waste of time. The first part below is how a normal person should write the Hello World app and then the second part is how to get Masa set up, just in case you too are a Maven fanboy (or fangirl). There are some notes at the very end about using Eclipse / ADT but I think writing the first app with the Android tools is helpful.

Android Tools

Step 1: Download Android SDK

Go to the Android SDK Download page and get the SDK. For the Mac, it is a ZIP file so I downloaded and unzipped and then edited ~/.bash_login to add ANDROID_SDK and put $ANDROID_SDK/tools in my path.

Step 2: Create an AVD

To be able to test apps, you need to set up an Android Virtual Device. As you get familiar, you'll probably have multiple AVD but create an API level 3 AVD to get started. I called my AVD basic. The steps below show me creating it and then starting it.

$ android create avd -n basic -t 3
Created AVD 'basic' based on Google APIs (Google Inc.)
$ emulator @basic

At this point, I see a window with a red phone. The screen on the phone is blank.

Step 3: Create an App and Install

I called my app buckets and the main activity is called BucketOverviewActivity. The android create call writes out a template project and sets up the initial metadata. Everything is valid as-is so you can go straight from there to compile and install the app.

$ cd ~/projects
$ mkdir buckets
$ cd buckets
$ android create project --target 2 --path . --activity BucketOverviewActivity --package com.unknown.buckets
$ ant debug install

After the install step, the phone appears to turn on and the app is now available. The name of the app is BucketOverviewActivity and when I click on that I see the Hello World.

Masa Setup

The Masa Web site appears to be stale and a different Maven project in GoogleCode has intentionally gone stale claiming that they are merging with Masa. I think that the problem is that the Ant tools provided with Android are good enough. Anyway, I spent all the time to get Masa setup so I may as well pass the info along.

Do the steps 1 and 2 above to get the Android SDK installed and in your PATH and to prepare an Emulator. Next, install Android JARs into the local Maven repository.

mvn -X install:install-file -Dfile=/usr/local/android//platforms/android-1.5/android.jar -DgeneratePom=true -DgroupId=android -DartifactId=android -Dversion=1.5_r1 -Dpackaging=jar
mvn -X install:install-file -Dfile=/usr/local/android//platforms/android-1.1/android.jar -DgeneratePom=true -DgroupId=android -DartifactId=android -Dversion=1.1_r1 -Dpackaging=jar


At this point, you can pull the Masa source and install Masa into the local repository.

cd ~/oss
svn co http://masa.googlecode.com/svn/trunk/ masa
cd masa
mvn install


Finally, you can take the sample pom.xml from the Masa Web site, update the versions, and put it into your project directory (that already has a find build.xml file for Ant) and use mvn.

Eclipse / ADT

The Android Developers Web site has great information for getting started with Eclipse and the Android Developer Tools plugin. Some parts that I think are important are that the code-path to create a new project using ADT is different than just using the Android tools. It isn't a real big deal but the best way to get a decent build script for a build machine is to use the Android create tool. I did find that I could drop a build.xml, build.properties, local.properties, and default.properties into the project directory of an Eclipse-created project and it built and behaved as I expected.

I tried Export -> Ant Build Files but that was terrible. Use android create at least once to get the good scripts. Once you get good build scripts, it would probably be smart to tell Eclipse to only use the Ant build script that was put in place but I'm going to live on the wild side and use the IDE build when doing interactive dev and Ant for 'real' builds.

ADT provides a graphical tool for managing the virtual devices, automatically assumed debug keys on Run As, and has the usual benefits of syntax highlighting and refactoring. There isn't an integrated tool for managing the emulators, that I have seen; that means that once an emulator is started, I have to kill it outside the IDE if it needs to be killed. Along the same lines, I've had a case where the IDE wouldn't start a new emulator but there was one running and ready to take an application image.