Android Fragmentation for Game Developers

I came across this post on Reddit today which itself refered to a Slashdot comment. To me it was especially interesting as the commenter refered to issues i talked about on this blog a while ago and they all relate to game development issues. Namely issues with VBOs on different hardware platforms, the nasty direct buffer garbage collection bug of PlatformAddresses in Android 1.6 and related direct buffer issues and finally the issue with selecting the best performing depth buffer size when constructing an egl surface. Now, the last bit seems to be handled pretty well by GLSurfaceView in most cases even though all it does is enumerating all egl configs and chosing the one nearest to a default config (via L1 norm afair).

Those problems i just mentioned are all OpenGL related. There’s a couple more of course: fill-rate limitations on next gen devices like the Nexus One and the Droid which result in “worse” performance on those beefier devices compared to say a HTC Hero, e.g. the space invaders clone i did for the german game dev tutorial runs at 60fps on the Hero and at around 40fps on the Droid due to a full screen background image. The notorious touch event floods which also bog down the CPU on all Android versions, but most prominently on 1.5/1.6 devices (Robert can sing a complete opera about that, go ask him…). Finally the last thing of the top of my head is the multitouch being totally useless on any current device apart from simple pinch zoom gestures which don’t depend on coherent pointer indexing and exact locations.

Now, all those “issues” can be seperated into two types of problems: Android specific problems and hardware specific problems. Google does mostly a good job at eliminating all the Android specific issues like the direct buffer leak with each new iteration of Android. Some things just aren’t all that important to them it seems so they don’t get any love for the time being like the CPU consumption (which is less prominent on second gen phones like the Droid). In case of those Android specific issues the fragmentation for game developers stems from lazy hardware vendors that don’t update their older hardware like the HTC Hero to new Android versions. This might be motivated by many things i don’t want to speculate about here.

While this chart might be biased (people with newer devices that have Android 2.1/2.2 will of course use the market a lot more than people that got their device months ago) it clearly shows that there is at least a trend towards the latest Android versions. This will ultimately help us game developers overcome some of the “fragmentation” issues due to bugs/inconsitencies in older Android versions that vanish more and more with newer Android versions. For the time being we still have to work around some of the issues as we don’t want to give up the market of 1.5/1.6 devices. Unless Google pulls a memset with future Android versions and introduces another bunch of issues that wreck havok with our games we can assume that these kind of fragmentation problems will go away. Froyo seems like an exceptionally stable distribution already.

The other category of fragmentation problems are hardware/vendor specific. The sad news is that neither Google nor we developers can do anything about this. This is especially bad for small developers which own just a few Android devices and therefore can’t possibly test their games on all the hardware that’s out there. As funny as it sounds but exactly this fact is the strength of Android. Vendors can decide to put out cheap and crappy Android devices as well as high end power houses like the HTC Evo. For the end user this is great as she can chose whatever fits her budget. For us game developers it’s a nightmare as cheap also means worse GPUs, touchscreens and so on, all with their own unique quirks which we have to workaround.

But is this situation so horrible? I remember some friend of mine mentioning a couple of times how shitty the transitions between the few IPhone OS updates were for him as a developer, with new versions breaking old code. From my personal experience on the PC i can say that it’s even worse there with the gazillion of different hardware and software configurations around. So what did we do on the PC? We shared the knowledge about quirks, eventually build some helper libraries which would take care of system specifics and so on. Yes, this is a major pain in the ass but it worked out for us (even back in the old DOS days…). This is the price of freedom of choice and i rather pay that price than being locked into a system which might or might not allow me to publish the work i do in my spare time.

Fragmentation is real. Some of it can be solved by Google and they seem to do a good enough job at that front. Most of the things that affect us game developers are the responsibilities of the hardware manufacturers. There’s nothing we can do about it. So let us stop whining and try to make the best of it by sharing the knowledge each of us acquired while working on Android. We did it on other platforms without ever complaining. Instrument your applications to get some real data, interact with your users if possible and share what you know with others. This is the only way we can work against the fragmentation issues. If it turns out that one manufacturer is more sloppy then the rest than maybe we could even generate some bad press to put some pressure on them to produce better products (yes, i’m kinda blue eyed :)).

I had to get that out of my system.

p.s.: We can of course bitch slap Google from time to time if the fault is in their framework 🙂

6 thoughts on “Android Fragmentation for Game Developers

  1. Nice post in regard to the various pain points.. I perhaps was a little overreaching on my recent posts on A&M regarding fragmentation. Part of that is me just being terribly anxious about the forthcoming effort of mine which as much as I’d like it to be perfect on initial beta launch it may not be.

    I think it’ll be a much easier existence when there is a good body of public knowledge out there regarding game dev oriented fragmentation concerns. As a whole we’re just beginning the journey.

  2. A very thoughtful post, you bring up some good points.

    You can contact our Developer Relations team when you find a problem with a specific device. We have a team that works directly with OEMs, and if the DevRel team is aware of a problem with a device, they can work through that channel to make the OEM aware of the issue. We have resolved a number of compatibility issues this way. When possible, we add a test case to our Compatibility Test Suite to ensure that it won’t happen again.

    And we deserve slaps when we screw up the framework.

  3. Hi Dave,

    i wasn’t aware of the Developer Relations team. I’ll definetly check that possibility out if the need arises.

    Thanks for the info.

  4. Dave this is good info. I have 2 simple 2D and 3D performance tests I’d like to get into the Compatibility Test Suite that will show rendering performance issues. Most notable the Droid w/ 2.1 update has improper capping on 2D rendering and the EVO 4G unfortunately has improper capping of both 2D and 3D (OpenGL ES) performance. Two very simple tests can show these issues clearly. In contrast the N1 with stock 2.1 and the FroYo RC (early leak) does not have these issues and it’s night and day comparing the EVO 4G to the N1.
    Perhaps Mario can share the contact to the DevRel team and or you can get in contact with me at the contact email address on It’s great to hear that Google takes a proactive stance with OEMs on these matters because likely the issues I mention were created through whatever the OEM/carriers did to prepare the ROMs and not something within Google’s control.

  5. Sorry Mike, i couldn’t find any info on the web about the developer relations team. Asking in the IRC channel on freenode might help.

Leave a Reply

Your email address will not be published.