And then there's Android.
I work every day with Visual Studio and the .NET Framework, and I've dabbled with iPhone development, so perhaps I'm spoiled...the stuff "just works" (at least for simple stuff). But my attempts to install the Android tools were an exercise in frustration.
The Android developer site provides lots of great, well organized information...so I knew that I had to install 3 different items to get up and running:
It started to get interesting when I had to figure out exactly which version of each of these I needed (since they all need to play nicely together), and found that the current version of Eclipse (Helios v3.6) is incompatible with the Android SDK, so I needed to install the previous version (Galileo v3.5). No biggie. Install different version of Eclipse.
And I needed to install the ADT Plugin for Eclipse. OK, done.
And I need to configure Eclipse so it knows where the Android SDK lives. Gotcha. (C:\Program Files (x86)\Android\android-sdk-windows was my location, for those of you who may be playing along at home.)
Things got a little more interesting when fired up the Android SDK and AVD Manager to create my first virtual device (i.e. the phone emulator). Ah, but which of the 5 different available versions of Android should I target? The latest and greatest is Gingerbread (v2.3), so I figured "Cool, I'll go with that!" I gave it the very clever device name of "gingerbread", and all seemed right with the world. But when I tried to start my shiny new virtual device, I got an error: "could not find virtual device named 'gingerbread'".
Grrrr.
A little digging, and I found that for some inexplicable reason, the virtual device had been created under a different machine user account, so the AVD Manager couldn't find the files it needed. Well, I can just drag and drop the files to my user directory.
No joy.
Well, I can just change the default location the AVD Manager uses when it creates an AVD. Dig, dig, dig. Ah, I can specify the location of the AVD files...by using a command line utility. Seriously? A command line utility?!? It's 2011...the year AFTER we make contact. WTH?
I find the syntax, and after much frustration (apparently it's both case-sensitive, and the order of the switches must also be important...because the example I copied and pasted from the page didn't work) I get it to work. I also figure that maybe the latest and greatest Android version isn't quite ready for prime time, so I revert back to the previous version (Froyo v2.2). So I now have an AVD (called "froyo") created in the location I wanted using the following:
android create avd –t 4 –n froyo –p c:\users\wloescher\.android\avd\ --force
(And don't get me started about TargetID vs. Version Number...sheesh!)
But of course this AVD doesn't show up in the AVD Manager, so I can't just click a button to fire it up. So by this time I'm calling in some help from my co-worker (who actually owns an Android phone and has gotten all this stuff working just fine on his machine). He comes up with the following command line to actually launch the virtual device:
emulator -data c:\users\wloescher\.android\avd\userdata.img
A minute or two later, and the virtual device is booted up and I have a virtual Android phone screen. Great! Now all I have to do is write a little code, and I'm done...right?
Wrong. There seems to be a disconnect between Eclipse and my AVD. The code seems to run fine (i.e. no errors), but nothing happens. Nothing. Not an electronic sausage. Just this error in the console:
[2011-01-06 10:43:11 - HelloAndroid] Android Launch!
[2011-01-06 10:43:11 - HelloAndroid] adb is running normally.
[2011-01-06 10:43:11 - HelloAndroid] Performing com.example.helloandroid.HelloAndroid activity launch
[2011-01-06 10:43:11 - HelloAndroid] Automatic Target Mode: launching new emulator with compatible AVD 'froyo'
[2011-01-06 10:43:11 - HelloAndroid] Launching a new emulator with Virtual Device 'froyo'
[2011-01-06 10:43:11 - Emulator] emulator: ERROR: unknown virtual device name: 'froyo'
[2011-01-06 10:43:11 - Emulator] emulator: could not find virtual device named 'froyo'
So...what have we learned?
Well, first off I'd like to thank the fine folks at Microsoft and Apple for making development tools that have a low cost of entry. Secondly, I hate the command line. Thirdly, I picked up a few new (to me) command line trick from my (very patient) coworker Michael Sneade. Fourthly, don't get involved in a land war in Asia. (Or was it don't bring a knife to a gunfight...I can never remember. Maybe it's both. Probably both, yeah.)
And fifthly and finally...if you want people to embrace and be excited about your development platform, don't frustrate the hell out of them right out of the gate. Goodbye (at least for now) to the world of Android...let's see how quickly I can get up and running on Windows Phone 7 and XNA Game Studio.
------------------------------------------------------------
UPDATE:
I was finally able to get the "Hello World" sample app to run in the emulator by adding a new Windows user environment variable:
1. Start Menu > Control Panel > System > Advanced System Settings (on the left) > Environment Variables
2. Add a new user variable (at the top):
Variable name: ANDROID_SDK_HOME
Variable value: C:\Users\WLoescher
I good friend reminded about Google's App Inventor (still in beta), and I'll do a post about that experience soon...it's very cool!
Yeah, finally I've gotten it to work. My user path contains non-alphanumeric characters, so this shit couldn't find the files when I tried to run the virtual device. It started to work when I moved the virtual devices folder (.android) to another path and created that enviroment variable. Jobs bless you!
ReplyDeleteYou must not forget about the Android SDK vs. Java JDK issue! When you've got the Java JDK installed (which is obligatory to code for Android) Android SDK still won't install, saying you don't have the JDK installed (that's right!).
ReplyDeleteThe workaround is to click the Back button in the very same window and then click the Next button again (that's right!). A miracle happens - the SDK can see the JDK without any problems!
Hi there !
ReplyDeleteThanks a lot for your very useful blog.
Nevertheless, I didn't solve my issue.
My problem is that my first name is "Régis" (with an accent) and that the AVDs cannon be found in C:\Users\.android\avd at runtime.
So I have got the errors:
[2011-04-04 16:10:11 - Emulator] emulator: ERROR: no search paths found in this AVD's configuration.
[2011-04-04 16:10:11 - Emulator] Weird, the AVD's config.ini file is malformed. Try re-creating it.
I added a new Windows user environment variable:
Variable name: ANDROID_SDK_HOME
Variable value: C:\Users\Régis
But still have the error !
Actually, I even don't understand how just the addition of this environment variable can solve the issue. Is there another operation to do ?
Please answer to regis.andre@2001.ecam.fr
Thanks a lot for your answer.
I feel your pain I chose an android project for my dissertation and I am about ready to throw both my laptop and phone out the window!!
ReplyDeleteOk everyone,
ReplyDeleteAfter some fiddling around I managed to figure it out. Hopefully here is a clear explanations of the issue and what you need to do to solve it.
First of all, this happened to me because my folder in windows has non-standard characters (é in my case).
What you need to do is first find what is the abbreviated path to your folder in windows. You do this by going in the command line to the parent folder of the folder with the strange characters, then you type dir /x. This will show you the abbreviated name of your folder. Make a note of it.
Then you go to and add an environment variable ANDROID_SDK_HOME as mentioned above and its value will be the abbreviated version of your folder.
Restart Eclipse if you had it open. Delete any AVDs that don't work. When you open the dialogue to create a new AVD (the Android SDK and AVD manager) you should see that just above the list of AVDs it says: "List of existing Android Virtual Devices located at: ...." and this should show the abbreviated version of your folder. If not, it hasn't worked, so try again.
I hope this helps.
José
I have been fighting with this for several days now and I FINALLY got my AVD running now it seems. At least it popped up the virtual device, now I just need to figure out why the hello world app isn't running. But thanks... I was starting to give up completely.
DeleteIf anyone is having problems with the Android SDK Path. Instead of using
ReplyDeleteC:/Program Files/Android
use
C:/PROGRA~1/Android
Eclipse doesnt like spaces in this folder name, so eclipse cant see the SDK. Just a wee tip
Agreed, commandline WTF...
ReplyDeleteI can see that you haven't had the displeasure of working with open source tools. In the FOSS world, almost everything is as unfinished and unpolished as that, and an hour or two of googling before being able to get a piece of software running is considered normal.
ReplyDeleteYou just have to deal with the fact that it's a different culture. Also, Android is a child of Linux, where the command line is considered the pinnacle of user interface design, but at least Android makes a good job of not exposing end users to the CLI.
You make a good point, John.
DeleteCuriously, I found a lot of the same pain points working with XCode and Objective-C. Apple has improved their deployment (both to devices and to the App Store) significantly since my last attempts a couple years ago.
I have to say that Microsoft still wins hands down on the maturity of their development tools, and that I continue to be impressed with Windows Phone 7. (But why the heck don't they have a screen shot function on the device?!?)
Grmbl... in my case it picks up my redefined user directory fine in the AVD (G:\myusername). Except that when it starts, it starts the correct AVM but at the wrong location: C:\users\myusername\.android and then it returns to forward slashes.
ReplyDeleteSomeone did NOT check this.
Emulator and avd-manager are indeed a pain, although I didn´t have problems installing the full package, creating an avd and starting the emulator at first.
ReplyDeleteThe emulator was very slow, but I found something on stackoverflow, that was supposed to make it faster, but didn't work. I tried creating a new avd with different settings. But the tool didn´t react for really long ( > 20 min). Killing the process maybe wasn´t such a good idea, because after I was not able to delete my first avd, mksdcard was still using it, but refused to be killed.
However, having the avds under your user account, is not a good solution really. System shut-down takes years with only one avd, if your profile is domain based. But after that I was able to delete the 18Gig big avd, and was really annoid, or was it android.
Finally I got the emulator working by changing the android.bat in my android-sdk\tools folder. Replacing "call %java_exe%" with "call %java_exe% c:\somePath" (found that in some other helpful post). Then started the avd-manager again, and believe it or not it created the avd at that place.
But then the emulator wouldn´t start it, because that thing still looks for the ini under c:\users\....! So I copied the avd´s ini file to the .android\avd folder under c:\users\myAccount. Not before having tried starting it with all sorts of commandline args, but it never did it properly.
Maybe now after a day or so wasted reading unrelated articles and documentation wihtout succes, I can start using the emulator as expected.
Really liked Your article and I must agree, commandline tools suck, especially if they require an armfull of arguments.
(Some years later)
ReplyDeleteGreat Job!
I found this article via
http://stackoverflow.com/questions/2841766/possible-to-change-where-android-virtual-devices-are-saved
I have the issue that I have two partitions on my harddrive so the "Android Virtual Device"'s pollute my system partition and I don't like to resize it.
Finally there are two solutions to solve this issue. The first one is to create a symbolic link from the path the AVD's are located normally to the path someone likes to store them in realtime. The second one is, how you already mentioned, to set the environment variable "ANDROID_SDK_HOME".
I prefer the first one but according to your article here is the Windows solution for the second issue you can store with the installation files together.
Use the "SETX" windows command to set a user variable. I found it in the discussion as follows.
http://stackoverflow.com/questions/3803581/setting-a-system-environment-variable-from-a-windows-batch-file