Item — HN Reader

Another area that can be quite tricky is games.

Most (but not all) Android phones being produced today support OpenGL 2.0 - even so, there are lots of tricky differences.

The obvious one is different screen sizes and resolutions. This can be a challenge, particularly for 2D games. You need either different versions of artwork, resolution independent artwork (through 9png, vector graphics, or something else), or to accept that your art is going to be stretched on most phones.

Additionally, different combinations of GPU/screen size have vastly different performance characteristics. A phone with a 720p screen might very well have the same GPU as a phone with an 800x480 resolution screen. Guess which one performs better? This requires a lot of testing, as the stereotypical "low end phone" might actually perform better than the latest and greatest with a giant screen.

Phones also differ, and sometimes greatly, based on the graphics chip/driver. HTC phones often don't preserve framebuffers in the way most other manufacturers do.

There are many more: non-po2 textures, compressed texture support, different context preservation behavior based on phone and OS version.

Games may not be the stereotypical application here, but they're a huge part of the market, and Android fragmentation has made developing performant, good looking games much more of a challenge than on iOS.

3 comments

I'm pretty sure OpenGL ES 2.0 (pedantry: not at all the same standard as OpenGL 2.0) was a platform requirement for everything from Eclair (Android 2.0 -- the Nexus One) forward. I'm sure that factory-new Android 1.x devices still exist in the market somewhere, but you'd be very hard pressed to find one. Note that the original iPhone and 3G didn't do GLES2 either, so the platforms got the support at roughly the same time.

The bit about pixel-perfect art matters to some, I guess. PC game vendors have been doing resolution-independent games for decades now, so it's hardly a killer. But if you have to have it, then you're stuck with the iPhone (not even iOS, obviously, as you'd have to chuck iPad support).

And the rest is just saying that "OpenGL is hard". Yes: if you want to code to precisely the extension support and bug-for-bug quirks of one GPU (presumably the PVR SGX 5xx in your case), then it's easier to support just that phone. Duh. But that seems like bad practice to me. What if Apple goes with Mali or Tegra3 for the iPhone 5?

There are some new devices (I'm looking at a Huawei M835 running 2.1) that don't have 2.0 support.

As for "OpenGL is hard" - I think a major point here is that Apple has made it far less so. Because of their extreme curation of devices (re: only Apple produced devices), and the ease of software updates (well over 30% of phones are upgraded to the latest iOS version [1], with > 80% on a 5.x version [2]), iOS has continued to be a remarkable homogenous platform.

As far as Apple choosing a new graphics chip for the new device, it's certainly possible. With iOS, though, you can support a known list of devices and have 100% coverage rate. On Android you either have to whitelist phones (and therefore exclude users), or try to do feature detection at runtime to enable the correct codepaths.

[1] http://david-smith.org/blog/2012/05/11/ios-5-dot-1-1-upgrade... [2] http://david-smith.org/blog/2012/03/10/ios-5-dot-1-upgrade-s...

It's deeper than "OpenGL is hard." Right out of the gate, you are hit with the one-two punch of different texture compression formats being supported on different devices combined with a maximum APK size on Google's store. The only standard Android texture format with compression is ETC which doesn't support alpha. So right at square one, if you want to use compressed textures for maximum performance and resolution, you have to release 3 separate APK's with a different supports-OpenGL-texture tag in each manifest. One for DXT, one for PVRTC, and one for ATC. Or dynamically download megabytes of textures after detecting which GPU you are running on.

That's a sharp contrast with iOS's unified, simple developer story: all PVRTC without any maximum app size.

That's not iOS's story, it's Imagination Technologies' story. The story from Apple will change the moment they ship a device on someone else's GPU. If this is something you expect to rely on, you're in the position of someone writing Altivec code in 2005.

But yes: texture compression formats and hardware support are a terrible, terrible mess. Happily I believe the early patents on S3TC are set to expire soon.

A minor addition: Android supports OpenGL ES 2.0 since Version 2.0, but JNI bindings to access the library from Java code are only available since Android 2.2 (API Level 8).

I'll be the first to criticize Google for not working even harder with manufacturers to standardize Android more or faster, especially when it comes to upgrades. But it's important to remember that iOS only covers a handful of devices at most, and they are all made by the same company, and use 2 or 3 different chips at most.

Any other OS which tries to cover more devices and configurations than that will inherently be less standardized and "harder" for developers, especially in its first few years of existence. There used to be a lot of different GPU manufacturers for PC's out there also 15 years ago.

These sort of things tend to become more standardized after at least a few years have past, and not only the OS is more compatible with different hardware, but there are fewer manufacturers to worry about, too, once the leaders of the market have been set, and the manufacturers themselves work on making their own hardware and drivers more compatible with previous versions once the market is stable.

The author actually says that Android fragmentation is less of a problem than on the web or even on Windows! If that's true, then Android is already doing very well regarding supporting a ton of devices that are still compatible with each other. But again, I still want Google to constantly work hard on making it as small of a problem as possible.

Agreed. In my experience, there are so many points of change/breakage that fragmentation is absolutely a problem if you're doing anything remotely complicated. We do voice and use SSL - both get broken from time to time on a subset of devices for a multitude of reasons...a phone manufacturer re-introduces a bug they fixed two full releases ago, an OS update adds incorrect proxies that break SSL, some models introduce flaky over-sensitive touchscreens or enable a vibrate feature that's a bit off-the-charts, and so on. Troubleshooting these issues take time & serious investigative work (not to mention awesome, helpful users), too. And you can't anticipate what's going to break ahead of time the way you can with iOS - you don't have access to carrier updates across the board and you can't possibly test every device/OS combo or upgrade case. You could take, for instance, ICS straight from Google, but that's missing all the breakage that gets added from the carriers and phone manufacturers...you basically have to await the screams, then apply the tourniquet. There's not much "preventative care" available.

One of the great things Google has done to help in this regard (whether intended or not) is the ability to push out releases to customers within minutes without review. While there are many reasons this lack of review can be dangerous for users, from the development side, it's really fantastic to be able to push out fixes to affected users as soon as you've got them implemented and tested. I.e., at least you can apply pressure to that gaping wound quickly.

Very much looking forward to what the Motorola acquisition has in store and am staying optimistic--one thing I've noticed is that the "dominant handset" changes fast - for us, sometimes, in a matter of months. And when we have a pretty stable dominant handset, life gets easier (the HTC era and the calm before the ICS storm was kind of nice). If a stable, Google-controlled and well-tested Motorola phone becomes the dominant for a significant amount of time, this has the potential to be a very good thing for developers.

You mean like Windows ? Windows covers 100x more combinations of hardware than Android and suffers from almost none of the same issues.

I know, right? I'm going through the list of issues that happen for Android, and these aren't common PC issues. Resolution issues and render capabilities per screen size? Games pick resolutions and settings dynamically for best performance. We crossed these bridges long ago.

But at any rate, it seems like the OP is trying to equivocate "well it's natural when you do things like this", but I'm not buying it. When your direct competitor doesn't have that problem, you can't wave it away by saying "it's inherent in the model".

iOS is not a direct competitor of Android. Apple is selling iOS devices. Google is distributing the Android platform to hardware manufacturers so they can sell mobile/connected devices.

So yes, there is no way that Android hardware & software fragmentation is going away. Just like there is no way that web browsers fragmentation is going away (hello HTML5 moving standard!). I'm also pretty sure that iOS fragmentation will become more and more important (new iPhone screen... Apple TV ...).

I disagree. I would even say that it is as least as easy to support most Android-based devices than it is to support most Hardware running Windows.

In both platforms you run into very little issues for most apps, and you need to add support for lot's of different configurations if you write on the system level (Game developers can tell you a tale or two about this).

That's what libraries are for. There are some pretty good ones for 2d (Andengine based on Box2d for instance). It saddens me that more developers are not committed to developing/extending gaming platforms and shared code, and instead porting games from other devices piecemeal.

Absolutely.

At Game Closure, one of the foremost features of our SDK is our cross platform (all Android devices as well as iOS) engine.