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.

Re:Fragmentation is mostly FUD

[sortius_nod]

It's funny, I saw this article on my RSS and knew that the first post would be this. You don't give any reason as to why the fragmentation stories are FUD.

I am personally very hesitant to look at any android device due to the fragmentation. Hell, you have 1.6 devices being released alongside 2.1 devices. If this isn't fragmentation then what is?

As has been posted, read some comments from users about how pissed they are that their 1.6 device won't run certain apps or is lacking features that could be implemented by a 2.x release but their carrier won't deploy any updates.

While the fragmentation can't be squarely put at Google's feet, there's a shared responsibility between the hardware manufacturers, the carriers and Google to ensure that this doesn't happen. Unfortunately this hasn't happened and Android is headed squarely toward a cluster fuck.

Re:Fragmentation is mostly FUD

[WrongSizeGlass]

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

If the contract period is 2 years, and the early termination fee is based on the contract period, they better support the phones for 2 years.

Re:Fragmentation is mostly FUD

[Sancho]

The stories just say that fragmentation is killing Android, but they provide no evidence. They are making the claims, here. I have found no evidence that there's a fragmentation problem. There are apps that don't work for all devices, but iPhone OS has that issue, too, and it's only going to get worse.

Here, let me have a go

[DavidR1991]

"The thing is, nobody ever defined “fragmentation”"

Let me try: You have several different versions of Android 'in the wild' on different phones, different carriers, etc. There are different stances on whether these version of Android can be updated (based on manufacturer) etc. yadda yadda

Now, looking at that situation, I would say 'fragmentation' is more along the lines of 'Is it going to remain easy for to target Android phones in general considering how many versions currently exist [/not obsolete] concurrently?'

So yes, it is mainly about compatibility. But it also means (much like any other platform) if the version leaping continues (and so many versions exist concurrently all the time) playing to the 'lowest common denominator' of supported features will be required

hrmf...

[hitmark]

this should have been made perfectly clear from google's side from day one. Yet everyone kept talking about android marketplace as if it was a part of the android source until the first android based devices without marketplace showed up, and none could figure out why.

i only ran into it after ranting about google's mismanagement of marketplace access on some forum, and got a link handed to me.

another issue is that 1.6 required that a compatible device could function as a phone. So any device thats been in development since 1.6 was first released, wont have marketplace unless its a phone or stalls its release until they can get 2.1 or newer working and approved by google. And even then the max resolution of the screen is 800x600, and i think the screen size is in the 5-7" range.

basically, google is lagging badly behind where third parties want to go with android. And its not helping that marketplace is only really usable in select nations so far (and when a sim is inserted into the device).

Re:This doesn't solve fragmentation

[h4rr4r]

The hardware vs onscreen keyboard does not require two apps.

The iphone is not one platform, there are 3 different phones and there is about to be a forth.

Re:And in any mobile device

[hitmark]

3b) apple makes sure to plan for a "incompatible" hardware upgrade when most of the early adopter contracts about to expire, and therefor they will be looking around for a replacement anyways.

planned obsolescence is a "wonderful" thing.

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.

Re:This doesn't solve fragmentation

[ergo98]

The problem is (from an app developer standpoint) is that there are too many variables in the android world to code an app once to run successfully across the ecosystem.

Yet strangely many people are successfully doing this.

You have to design a version for on-screen keyboards (because it'll use part of the screen real estate) separately from a version that uses a hardware keyboard. They don't need to be separate apps, but you need to design (visually at least) for both scenarios, or you end up locking out a good portion of the people who use android devices.

Completely wrong. Where are you getting this from?

Sure, there are 100,000+ android devices out there

Over 100,000 Android devices activated per day.

so in order to sell your app on all 100,000 of those phones you've got to tweak your app for each device

No you don't. You have no idea what you're talking about. And you're at Score:4 right now, which is shameful.

One way to call the Camera API

Ugh. You shouldn't have posted because almost everything you have said is just completely wrong.

The Android developer platform is extraordinarily universal. There's a density independent pixel format (which is how an app looks almost the same on a 320x480 screen as it looks on a 480x800 screen), support for varying screen ratios, a single way to inter-operate with the camera and send emails and read the GPS signal and get orientation signals, or even do advance OpenGL graphics.

One app to rule them all.

There are of course differences and occasionally "quirks". If you make a rich graphics game it's going to run terribly on a G1. Flash is only available on some devices. And of course if you have to target a newer API, presumably because it has a feature that you can't live without, you limit your app to that version and above (just as if I use Transactional Filesystem calls my Windows app would be Vista or newer).