I’ve been intending to make this post for a number of weeks now, initially before taking part in the University of Portsmouth’s GameJam 2011. However, I spent the week before the game jam preparing, then the jam itself takes place over a week and finally I’ve needed the best part of the two weeks since to recover from it all!!! My post today relates to my first encounters and notes regarding developing for Android OS going back to April this year.

I’d initially downloaded the Android SDK shortly following it’s initial release, but as it was exclusively Java at the time, I knew performance for games was likely to be an issue (as was a lack of portability of the code to other games platforms), so I decided not to bother investigating further at the time.

Having attended GDC 2011 and given the recent release of the Honeycomb platform, I decided to acquire a Motorola Xoom and take the plunge with Android again.

The first step with working with a new platform is to install the SDK. The developer area on the Android site does a reasonable step-by-step job of guiding the user through the process of installing Android SDK, Ant, the NDK and unfortunately the Eclipse IDE. I’ve never had good experiences with Eclipse in the past, and it seems the same was destined to be true again. As I’m installing on Windows I initially allowed the Android SDK to install into the default ‘Program Files’ folder, but in a later install changed this (and other SDK components) to C:\Android to simplify path names.

Eclipse worked fine with regards to compiling Java code, the problems arose when trying to add the Native (code) Development Kit or NDK. It’s at this point the confusion caused by Google having released so many platform versions and NDK updates, in such a short time, raises its ugly head. Various Google searches, looking for clues as to whether NDK content should compile within Eclipse created an impression that such code didn’t actually compile within the IDE and that you had to drop out to a command line to compile such each time you needed to. Other sources however, seemed to indicate that NDK code could in fact be compiled from within Eclipse. A very confusing situation, not made any clearer by Google’s own build instructions.

I spent about 4 weeks (in my spare time) trying to ensure environment variables were correct, uninstalling and re-installing various packages, Eclipse plugins and even Motorola’s own version of the Eclipse environment which intends to take the pain out of the process by installing everything for you! But still the NDK content wouldn’t compile from within Eclipse. I even tried installing the OSX versions of everything and had no luck there either.

Eventually I attended a Motorola MotoDev event in London, and after hassling a support technician several times, I was able to determine that NDK content should be able to compile from within Eclipse, but as luck would have it, their demonstration machines weren’t configured to support NDK development on the day… So no luck there finding the cause of my problem.

Any novice developer would have probably given up weeks ago, this is a shocking state for an ‘OS SDK’ to be in.

I eventually determined that the issue I was having was due to the most recent updates to the NDK SDK, apparently Google had changed the directory structure for r5 from r4, so a third party plugin enabling compilation of C/C++ code within Eclipse wasn’t working. What didn’t help with the confusion however was that the plugin’s developers were reporting having fixed it to work with r5, so why wasn’t it working for me? At the point of giving up I realised that I was using the newly released (at the time) r5b release! Oh my! Even a subversion change had also broken the C/C++ plugin! All of this chaos was compounded by the odd behavior of Eclipse which would crash, show dialog errors and generally had a difficult time doing its job as an IDE.

Google don’t seem to provide links to previous versions of the NDK on their site, but I was able to download other versions by guessing and manually editing the URL for the current SDK version to access the others.

At this point I gave up with Eclipse, it seemed unstable, and I’d already spent over 4 weeks (admittedly not full time) trying to get a tool that should increase productivity to work and I just had to get on with something productive or call it a day for Android. I’d have to go back… Back to the Command line!!! (cue BTTF soundtrack).

I should have done this in the first place. While feeling very retro 1990s, a similar ‘hacked’ environment to home brew Nintendo Gameboy development kits (where only minimum tools and no useful debugger were available), I was finally able to actually get on with some actual development!!! I’m now in a situation where I can compile and run code for Android, then take the app specific code/assets and rebuild them to run on iOS, which is pretty cool and lets my aging MacBook Pro take a rest during the grunt work.

Following are the notes I made for myself, regarding the fundamentals of command line compiling for Android, some of you might find them useful:

Android Command Line Building

The cygwin command line won’t see the ‘android’ command even though it’s in the path, needed to explicitly include the .bat extension.

To begin use cygwin to init a project for first time use with ->

android.bat update project -p .   (note the trailing . is the project path param)

Then use the cygwin prompt to do building (from within jni project folder) ->

ndk-build

The above compiles the C/C++ code into a .so library file.

Then need to compile the Java components and create the .apk (zip) file for installing on a device with this ->

ant debug

To deploy the resulting apk to a device use this ->

adb install -r bin/xxxxx.apk (where xxxxx is name of resulting package name, see the output from the ant stage, remember to include -debug part of filename)

I’ve not tested but the following may launch the package, I tend to launch the app directly on the device itself ->

adb shell am start -n com.example.yyyyy/.ActivityName (where yyyyy and ActivityName match same in app)

When I need to uninstall an app, possibly due to a certificate error (due to changing dev machine) use –

adb uninstall com.example.yyyyy (which is the Java path for the app).

Apart from adding the Ant and the Android tools folders to the PATH environment variable, the only other env variable I had to create was –

ANDROID_NDK_ROOT which was set to c:\android\ndk in my case.

To avoid the certificate error when developing on several machines it is possible to copy a ‘debug key’ from one machine to another.

The key should be in a store, debug.keystore which might be located in ~/.android/ directory (This is within the User folder on Windows).

I hope something from the above notes might save someone a few hours searching the Internet!