Sunday, November 27, 2011

Non-ARM Android Apps

I've had 2 requests now for my Lords of Midnight remake on x86-based Android devices. A while ago I updated the scons-android build system I use to support multiple architectures, but I didn't actually upload an x86 version to the Market. I thought nobody actually owned one of these mythical devices. Turns out that times are changing.


Back in July, Google added multiple APK support to the Market. Sadly, the multiple APK idea is a bit limited in what you can do. The APKs have to be different in one of 3 key features only. These features are Open GL texture compression type, screen size and API level. Differences in other features - such as whether the device has a touch screen or not, has a hardware keyboard or not, the type of processor it has, and so on, are all ignored. If the only differences between the APKs are in these "minor" features then they are considered identical by the Market software and will not be allowed to coexist.

The explanation I've read as to why this is the case is that the Market client application on devices doesn't provide enough information to the Market server for it to make use of all the feature filters. This makes some sense, as there have only really been multiple ARM ABIs available since June 2010 with release 4b of the NDK. But the Market does already know how to hide non-compatible APKs from you, so I get the feeling this is more a case of "we can't be bothered to do this" rather than "we can't do this".

As it stands, in order to do an x86 version of an app that uses native code while still maintaining compatibility with the majority ARM devices, you need to provide a so-called "fat binary". This is an APK that contains a copy of the ARM version (versions) of your library and the x86 version too. I think it's a bit of a shame that users with one type of processor have to pay the download-tax due to the inclusion of its "evil twin" opposing processor library. Fortunately the Android installation tools are smart enough not to copy useless libraries onto the device for use at run-time, so it is only the increased download size that is a problem.

With this in mind, I've uploaded a new version of War of the Solstice and Chaos that support x86 too. Since I don't own anything that I can actually test these on it is a stab in the dark - it may work, but it will likely just crash, let me know with your 1 star reviews! ;-)

Screenshot of the strange Android Market upload warnings
One thing that worried me slightly is that when you upload an ARM/x86 dual APK to the Market it says "this apk requests 2 native platforms that will be used for filtering". That makes it sounds like you need a strange ARM and x86 device to make the game work. I hope that this is just a typo, and that the final APK works on just about everything.

Tuesday, November 01, 2011

3D Space Game Bug Fixes

Back in July I wrote that I was working on getting rid of the bugs in 3D Space Game. It has certainly taken me a while to get most of them squashed, but I've just uploaded a new version to the Android Market [edit - no longer available] that fixes many crashes (hopefully!). You can also view the source code on the googlecode site [edit - no longer available].

One of the nasty side effects of the old version was it's battery hogging behaviour. This was caused by my dreadfully inefficient Game Boy Advance-like emulation layer that was baked into the game. Over the last few months I've also improved my android-ndk-profiler so it works a lot better on older devices, and I've used it here to try and get better performance. Even with that I still did most of my tuning and debugging on the SDL and Linux port - Android is still missing something like valgrind for native code and GDB doesn't work prior to 2.3.

For the umpteenth time I learned the following lesson: if an (Android) application crashes, chances are it is because I am writing past the end of a buffer into something important! Let's see if the lesson sticks this time :-)