Android Compatibility and Fragmentation

tbray writes "Here are the details on the Android Compatibility Program — which combines the source, a formal compatibility spec, an open-source test suite, and access to the Android Market as reward for good behavior (program page). People like to rant about the subject of fragmentation, so here's TFM that they should be R'ing first."

Comments

Fragmentation is mostly FUD

[h4rr4r]

Fragmentation is mostly FUD, there are only a few screen sizes and the OS changes are pretty minimal.

Re:Fragmentation is mostly FUD

[WrongSizeGlass]

From the Android developer blog

Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.

Re:Fragmentation is mostly FUD

[Fnkmaster]

Agreed on screen changes. But there's a major psychological issue with people shelling out hundreds of dollars for what they perceive as the "latest, greatest" phone, and then 6 months later being told they are stuck on version 1.6 when we've already gone through 2.0, 2.01, 2.1 and are about to see 2.2.

If you think this isn't real, go see the thread on Engadget right now on this topic. People are angry about it. Frankly, I'd be pretty angry if my phone was still running 1.5 (apparently a third of Android phones out there are still stuck on this old-ass version as of a few weeks ago, and a third or so were still on 1.6, with another third on 2.1).

Mind you, almost every phone has at least an *unofficial* community-produced ROM that will get them the 2.1 features and apps. Even the klunky G1 which was the first Android phone can get there - it's just not officially supported, presumably because Google, HTC and T-Mobile don't want to push down an update that replaces the SPL - I guess they think the support costs from doing that would be higher than the PR costs of not doing it.

So yeah, the issue is a bit overdone - or rather, it's not so much fragmentation of hardware specs that's the issue - I think allowing some hardware diversity is a good thing, it encourages innovation. The real issue is lack of hardware support from manufacturers and telcos after the point of sale. Google has up-to-now done basically nothing to force guaranteed support periods and guaranteed maximum release delays on a newly released OS version. I saw nothing in the article to address this.

*That* is the real issue that gets people riled up. *That* is what the users at Engadget are seething over. They want 2.1. They don't want to be told "we can't support 2.1 on your 8 month old handset, eat a dick" by HTC or Sprint or Verizon or whoever. Google is letting the carriers and hardware manufacturers release products, pimp them, then drop support 3 months later. They need to force some structure on customer support - I don't think every piece of hardware should be supported forever, but I think a year of official support for the latest version releases after the last date you sold the product is a minimum, and I think that a 2-3 month lag from Google's release of a new version to an officially supported ROM from the hardware vendor and carrier is a maximum. If a vendor falls outside of those parameters, every handset of their should be banned from the market, effective instantly.

That's the stick they need to support their customers. If Google doesn't man up and do this, I'm afraid it will do a significant amount of harm to the rapidly developing Android market.

It's a huge issue to app developers, not Googlers.

[pocopoco]

I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.

Some examples of bizarre stuff I have to do:
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?

Anyway, I'm constantly dealing with issues like this. 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.

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.

This isn't really surprising. 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. You can see a graph of the versions of the devices on Android Market here:
http://developer.android.com/intl/fr/resources/dashboard/platform-versions.html

And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.

So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.