Android ADT r17 released today.

[Updated, it's the ADTr17 that's was released]

Google released the final/stable version 17 of the ADT today. There are a number of fixes and improvements that almost make me feel that the fine folks at Google read my blog, or at least are inside my head, reading my thoughts - which is entirely plausible too.

Check out the full release notes here

Of special interest to me are:

• Better, automated jar dependency support: link
• "Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfigcontaining a DEBUG constant that is automatically set according to your build type." While this does not address my grievances, it's a step in the right direction.
• Hardware virtualization support for emulator images based on x86, link. I haven't tried it out yet, but I'm keeping my fingers crossed that this gives a much needed shot in the arm (see what I did there?) to emulator performance. *And yes, I know my pun didn't really make sense.
• Support for hardware GPU on the emulator: link. This is a big one!   Maybe the openGL support is better on the emulator now too.
• Fixes for Proguard, with the "Conversion to Dalvik format failed with error 1"issue fixed. I wasted an entire evening and then some on that once, though I eventually fixed it by splicing a newer version of proguard into my local ADK.

I have a new version of Sedition almost ready to go, with only minor tweaks needed (most of the time needed will be QA'ing my tweaks). I think I'll wait until I publish again before kicking the tires on this release.

--P

Sedition

After many months, and even a good deal of schedule slippage, I uploaded my game, Sedition, to the Android market. You can find it here:

Sedition Ad-Supported  and  Sedition Ad Free

I also have a Blog dedicated to my software endeavors, DigitalPopcorn

My baby

(Apologies to anyone reading this who might not be able to access it in the Android Market, I plan to expand offer to additional countries soon, as well as other distribution channels.)

Anyways, it is still in "Beta", but here is a run down of some of the technical/design details of it:

Android Library Management for publishing multiple editions of an android app

[UPDATE 12/30/11: This post is a little out of date, I recently updated to r16 of the ADK, and eclipse 'Indigo' (3.7). I had to play around with the library settings to make the dex process happy, and the settings actually make a little more sense now. I'll make a new post]

Sorry for the long title, but I spent a frustratingly long time( hours ) doing something that should have been achievable in seconds.  My hopes are that I am able to document the steps needed here well enough that someone can save themselves some time.

As a last step before publishing, I needed to be able to quickly make two versions of Sedition, an Ad-supported version, and an Ad-free, paid version. In the Android market applications are distinguished from one another by the "package" property in your AndroidManifest.xml file. So simple, change your manifest name and re-build. Not so fast, the resources in your application, eg the files that get assigned an id in the infamous "R" class, are built to live in that class. So when you change your package, any code that references anything in your R class will break. For me this resulted in over 100 errors. I have some final static variables in that help me define code behavior for any given flavor of build. This was the closest I ever got to a #ifdef type mechanism that I mentioned a few months ago. Unfortunately, there is no solution for changing manifest files in a similar manner.

The conventional wisdom of the Web suggests moving your application into an android library, then make two new "Applications" that then link to the library, like so:

This is what I did. It should, by all accounts, have been quick. It wasn't, there were a ton of booby traps, and unless you have innate knowedge of the inner workings of the android build tools, it's a little bit of a mysterious beast. Here's what I did:

Almost Live

My game, unless something goes wrong at the last minute, will get submitted to the Android Market this weekend. It's far from "done", but I think it is a solid "Beta" level app. All the planned features are mostly working.

I figured it was about time I opened up a little more about it....

Without any fanfare, here is:

Back in the solder again

I finally made an initial release of my game, Sedition, not yet on the market, but to a few people I know personally. It is not complete, I'm torn whether to call it 'alpha' or 'beta' at this point. At any rate I intend to 'flip the switch' and Google's and Amazon's markets within a week or so. More on that in a future post.

I also have a Blog dedicated to my game and any future software I release: Digital Popcorn

Anyways, one thing that working on this game has kept me from is doing hardware hacks. Now that development efforts have (hopefully) peaked on Sedition, I want to get back into it.

An alternative to the Android emulator and setting up ADB for TCP.

[Update 7/28/11 :See updated information at the end of this post]


I touched on it in my last post, but Android x86 running on Virtual Box can often (but not always) perform better than the standard Android emulator. OpenGL is painfully slow on either. I'm running one of their pre-built Froyo binaries, but Gingerbread source is on the site, if you're feeling adventurous.

The main advantages are:

• it starts up faster
• less prone to lockups the the SDK emulator
• it depends somewhat on what you're app is doing, but many things, like file system IO and math intensive code, seem to execute much faster

The main disadvantages are:

• Not very representative of a "main stream" Android device.
• Cant be used if you're using NDK with native code targeting the Arm processor.
• Configuration of things like screen dpi, and emulated hardware is not as easy or non existent.
• You can't emulate certain operations like SMS

A guide to setting up your x86 virtual machine can found here: (It takes less than 10 minutes) Install Android Froyo on PC

Launching Android-x86 is not automated like the emulator and ADB takes slightly more effort to setup, but it's not hard. So here's my quick-start guide

Android OpenGL ES texture management.

My Android game is still 'coming along'. I'll be making an announcement post soon. It's consumed most of my late evening "dad time", I haven't touched a soldering iron in a while, I'll make up for lost time later.

Progress on the game has generally gone like this: bang out some framework code, bang out cool feature, cool feature, find a minor bug, spend the next few evenings pulling my hair out, framework code, cool feature, cool feature, rinse, repeat. This post is about one of those hair pulling moments and my solution. It revolves around Android's handling of the OpenGL texture buffer management API's.

Recently, I was reworking my texture management code in my "engine" (if you can call it that, it's really just a few folders of Java files with a focus on lower level Graphics and my own Collision detection). I wanted to add the ability to have "dynamic" textures, ones that could be created and modified in the middle of a game in progress. Android has been fun to work with, but the there is a dearth of documentation when it comes to the 3D stuff, you are typically refereed to external Open GL ES docs, or to the SDK samples, which invariably don't do what *you* are trying to do.

Disclaimer: Though I have been in the video game business for a long time, I have rarely done low level graphics rendering work. I would not consider myself a guru in that area, so take this post as food for thought and not as an authoritative doctrine. If you think I'm wrong on something, call me out!

Java Conditional Compilation.

For a "main stream" programming language, Java has a few aggravating shortcomings. The lack of conditional compilation is one of them.