So, in its relatively short lifespan Android has seen a 1.0, 1.5, 1.6, 2.0/2.1, 2.2, 2.3 and most recently 3.0 release. As a developer, you need to decided which of these to target and which of these to ignore. In many ways, if you are using Unity or another engine it makes the decision easier, as they set a minimum level and abstract away the details in their own code. For the record, the minimum Android version supported by Unity is 2.0.
One of the most obvious factors in deciding what version to support is market penetration. Luckily, Google provides such information. This chart shows the OS version of devices that have connected to the market in the past 14 days.
Hmmm, pretty simple really when you look at it. Support Android 2.1 and higher and you are good to go.
From a developer perspective this is pretty true too. There were vast numbers of changes between 1.5 and 1.6, things you would think would be a no brainer like multi resolution support, but due to such small market numbers in the first place, I think we can simply ignore 1.5 and earlier. Trust me, they aren’t worth developing for.
From a game developer perspective Android 2.0 really isn’t all that different from Android 1.6 but there are a few giant gotchas, not to mention the various “undocumented” features.
First off, due to a move towards virtual buttons, HOME, MENU, BACK and SEARCH buttons now execute on key up, instead of down. These little changes cause all kinds of nightmares moving between platform versions.
Perhaps of the most importance to game developers, MotionEvent can now report multiple simultaneous touches ( aka, multitouch ). Also, if you are using the NDK ( C native code ), OpenGL ES 2.0 is now supported.
Really, that’s about it. There are other changes of course, support for bluetooth 2.1 profiles, better thumbnail generation, etc… but to a game programmer, not much else of consequence changed between 1.6 and 2.0.
This was the big daddy of all updates. First of all, they enabled JIT in the Dalvik VM, resulting in 2x-5x performance increase CPUwise over Android 2.1. Personally, I never experienced anywhere near that level of increase, but the improvement in speed is extremely noticeable. So first and foremost, your code is going to be faster running on Android 2.2. If CPU bound, in some cases then, your code is going to be MUCH faster on Android 2.2.
Besides enabling JIT there were a number of other changes of note to a game developer. One exceedingly big one is the ability for Apps to install to SD card instead of into the devices memory.
Perhaps biggest of all is that OpenGL ES 2.0 support is now available to Java based apps. The media framework also gained a few new abilities that are quite useful, like the ability to detect the completion of a sound loading in a SoundPool.
That’s about it, but then again… a massive increase in speed, the ability to load to an SD card and OpenGL 2.0 ES support… that’s a pretty substantial upgrade.
Android 2.3 is one of the first versions that actually looked at gaming as a priority. They improved the garbage collector to minimize pauses, which are killer to immersion. Nothing like having a 30fps shooter slow to a crawl because the garbage collector kicked in. They also increased the performance of touch and keyboard events and used a 3rd party OpenGL ES video driver to increase 3D performance.
In the feature perhaps most called for, they implemented OpenSL ES for native audio support. Up until 2.3, audio support has been at best weak on Android. Now expect to see a lot of audio applications from the iPhone show up on Android because frankly until now, they were impossible to implement.
For the very few games that require it, if you want to use a front facing camera, Android 2.3 is where support was added. Also added support for a slew of new sensors to enable Wii-esque actions, if of course the device has said sensors installed.
Really, in the end, the audio changes are the main event in the 2.3 release.
Unless of course you are doing Native Development using the NDK. If that’s the case, this release was huge. Until 2.3, you basically used the NDK to develop libraries that you called from a Java code. All your UI and event management code had to be done in Java. With 2.3, they added the NativeActivity class which pretty much allows you to work 100% in NDK/C++ code and kiss java goodbye.
This should result in a performance improvement and make porting to Android easier. My question is, will it fragment the market even more?
And this brings us to the most current release as of writing, 3.0. 3.0 was mostly about adding tablet and tablet UI support to Android, but from a developers perspective there were a few new additions that are handy. Lets go with the biggy first, Android 3.0 is the first OS release to support multicore processors. So I suppose you want to target that shiny new Tegra2, 3.0 is where you are going.
They also added new animation support, but that’s not really animation support in a way that a game developer would care, that’s more for flying bouncing windows and other annoying and overly abused eye candy.
They did however add hardware acceleration for 3D graphics. I am kind of surprised it took this long, but is definitely a welcome feature.
They also added something called Renderscript, which due to my ignorance may or may not be of use to game developers. I really need to look into it further, but for now I will let Tim Bray @ Google explain it.
Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.
Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.
The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.
Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.
When I get the chance I will look into this Renderscript a bit closer, but it does sound interesting. 3.0 is such a niche of installed devices however that it really isn’t a feasible minimum level to target at this point.
So in summary, 1.5 and earlier are so ancient and decrepit you are just as well as ignoring them. 1.6 is pretty much the “core” of the current API, but a large portion of the 1.6 install base will be running on old hardware where the resolutions simply may not be worth supporting ( like 320×480 ) in a game, so this generation may be skippable on that merit alone. Multi-touch and ES2.0 native support are the big draw to 2.0/2.1, while 2.2 offered a fair number of advantages. Simply put, 2.3 and 3.0 currently don’t have a big enough install base to bother supporting as your minimum target.
Therefore, and this is purely opinion, if I were starting a game today… which I suppose I am, I would look at 2.0 as my baseline target unless I really needed one of the new features or the performance gains that 2.2 offers. Luckily in my case, the developers at Unity already came to the same conclusion I have.
One last word of warning. In my brief time working with Android, I found version bugs to be a major pain in the ass, especially in code dealing with media. I had code that wouldn’t work in the emulator, that would only work in the emulator, that would work in 1.6, and 2.2 but not in 2.1. Put simply, Google have done a pretty terrible job at times in the forward/backward support category. With your code, make sure you test on as many devices and as many OS versions as you can. This single handedly is the reason I am not developing directly for Android any more. I spent more time, by a large magnitude, dealing with crap like this than I actually did developing. Of course, your mileage may vary!