Azkend 2 on Android ICS x86

It seems that there’s at least one x86 Android Phone available. That inspired us to try out our games on Android x86. This is something that won’t probably be relevant to mass audiences for a while if ever, but it was still interesting to see Android and Azkend 2 running on a x86 netbook. Most Java-based games work straight away and native apps like Azkend 2 need only to be recompiled.

However, with Medfield the situation is even better: It seems that Intel has integrated some kind of binary translation magic into the SOC which means that even native apps compiled to ARM will work without modifications. Many sites also report that the x86 battery hog myth was busted with Medfield and that devices can compete with the likes of SGS2 in terms of batter life.

So, from a game developer’s perspective supporting Android x86 shouldn’t be a problem if it becomes popular.

We used a live bootable usb stick created from a iso here on a HP Mini 100e. See Azkend 2 Lite running on an Intel Atom equipped HP Mini 100e here.

Android and the strange world of APK sizes

Google just upped the maximum single APK size to 50 MB. After this the developer needs to do some add-on package juggling up to 4 GB. This can be done with Google’s own tools or developers can roll their own. For us this small change meant that we could fit Azkend 2 in two single packages on Android: APK for phones and another for tablets. However, the reality of things proved to be a bit different.

We just released Azkend 2 Lite on Google Play and one of our own test devices is a HTC Wildfire S. It’s one of the cheaper Android 2.3 devices. After the release, we were baffled why we couldn’t find the game with that device. We saw no apparent reason why Azkend 2 Lite would filter out on a Wildfire S.

Turns out that the cache partition size where apps from Google Play are first downloaded varies from device to device. On the Wildfire S this size is 35 MB. On a Nexus S the size is 500MB. On a HTC Sensation the size was around 80MB. If the cache partition size is smaller than the app APK, the app will not be visible on the Google Play for the device. This is an interesting and unadvertised limitation that probably affects cheaper models more than expensive ones.

So, it seems that even the 50MB single download can’t be achieved on all devices. I’m not sure if there’s going to be a fix or if this is just a feature. From the little details we’ve learned, it would seem likely that this is something that could be fixed in Google Play. If there is a storage device with more capacity attached, why not use that for saving the apk? World of Goo by 2D Boy is also affected by this strange feature.

If you suspect that you aren’t seeing some apps with your device, you can check the cache size with a free tool called Cache Fixer. You can even move the cache on a rooted device. However, this moving fix isn’t an option for the majority of users.

The story of Mali-400 MP and GL_RGB

We’ve had our share of compatibility problems with Android but most of them were quite straightforward. That said, it has still taken a lot of time if you sum up all the little bits of work we’ve done to improve compatibility. Maybe this note will help some other developer solve this particular issue more quickly.

For some time we’ve received reports that some Galaxy Note devices and some Galaxy S II devices may have problems with our games. When we started investigating, we discovered that the trouble was with games that used frame buffer objects (FBOs) or render targets if you prefer that term. We already knew that despite the similar model names, there are several kinds of SGS2 and Galaxy Note devices.

Samsung Galaxy S2 has three possible SOCs (System On a Chip): Snapdragon S3, Samsung Exynos 4210, or a Texas Instruments OMAP4430. Galaxy Note has two possible SOCs: Exynos 4210 or Snapdragon 8255T. After some more research we discovered that the trouble occured on devices with the Mali-400 MP GPU which can be found from inside the Exynos 4210.

After we had narrowed down the suspects, some googling produced this. In the end it was all down to the following sentence.

You are trying to create a framebuffer object with RGB of 8-bits per channel. Mali doesn’t support this because of memory alignment issues that would impact performance.

We had used GL_RGB in our OpenGL ES implementation and it seems that Mali-400 MP doesn’t support this at all.  So, now we know that. All other devices we’ve encountered have supported it, so this was exceptional. The fix was obvious: use GL_RGBA. Further investigation also revealed that GL_RGB is an optional feature so our code was a bit too optimistic to begin with. Anyways, problem solved!

In the end, as a developer I’d really hope that manufacturers would use a different model name if they decide to use a completely different SOC. Even though your average user doesn’t mind what’s munching the bits, this situation makes a developer cry. Granted the manufacturers have used different technical model names, but our customer will say he has a Samsung Galaxy S2. Most don’t know that actually they might have a GT-I9100G instead.

You really can’t say that your app is tested to work on a SGS 2 if you don’t have all the three different devices. And that wouldn’t account for the operator tailoring which might also be a factor in some cases. With that you might have somewhere between one and two dozen different versions of SGS2. For most developers it’s impossible to acquire AND keep acquiring every possible common Android device so it would be great if the manufacturers wouldn’t make the situation even harder :)