I’ve raised the issue of Android fragmentation quite often when people tell me that Android is ‘here’ and that ‘Symbian is dead’. Symbian has had it’s fair share of fragmentation problems — they’ve been through a heck of a lot of teething troubles and they’ve come out the other end with a very powerful, reliable, proven operating system (that doesn’t really look as sexy as the competing platforms at the moment).
Most of the time people I’m talking to just smile and say I’m too much of a Symbian or Nokia fan to know. I then point out that much of the feedback on the Android market is from, for example, a guy using a Droid complaining that the app doesn’t work on his phone, or someone using a Nexus One warning not to buy the app because ‘it doesn’t work on Nexus One’. That kind of feedback is hugely worrying for consumers. It’s perfectly fine when the platform was being used by geeks who could root their G1 and do what they wanted with it.
It’s not good for end consumers who just want things to work.
How bad is the fragmentation issue? Well, it’s beginning to seriously irk some developers. Here’s a chap contributing to a Slashdot discussion on the subject.
Some examples of his frustration:
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don’t even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there’s no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?
Now here’s an interesting question. How committed is Google to Android? I mean really committed. Developers need these issues and niggles fixed properly and reliably.
It is really disappointing that Android team, the carriers, and the device manufacturers don’t do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google’s part to do it.
Here’s a good example of Google not really getting stuck into the discussion:
Meanwhile Google isn’t even interested in solutions to these problems from what I’ve seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like .NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.
Another damning point:
If you look at a recent app produced by Google, the Twitter app, you’ll see that it is unavailable to a huge percentage of the market because they don’t support older versions of Android with it. Independent developers can’t afford to ignore large sections of the marketplace like that. Google isn’t in the app business, so the Googlers just go ahead and ignore the issue.
Not good at all.