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:This wasn't his point, but.....

[amicusNYCL]

This wasn't his point, but the author of the article described the android fragmentation perfectly.

Actually, that was specifically his point. From the preceding paragraph:

Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.

..then he goes on to offer a definition for "Android Compatibility", and a few examples of problem areas (which you quoted). He then goes on to describe steps they have taken to mitigate the problems. The first step in solving a problem is to define the problem, and that's what he's doing.

Re:Screen res

[hitmark]

DPI awareness is mostly a problem if your GUI toolkit is pixel based, rather then vector based. Especially if those pixels have hardcoded limits.

all the major linux UIs are moving towards using vector graphics for instance, and i think microsoft headed the same way with vista and later (tho win32 legacy programs will still be a pain, and why microsoft wants to see xp and older dead).

Re:This doesn't solve fragmentation

[Darkman, Walkin Dude]

So fragmentation will ALWAYS be an android issue until they say "here is our reference hardware platform(s) -- you must use of these three sets of features when building hardware."

To an extent that's already happening. Phone goliath Nokia among others are setting up an alternative to appstore:

Twenty-four mobile network operators have formed the Wholesale Applications Community to avoid fragmenting the apps market and to give developers one point of entry to all the members, the GSM Association announced on Monday.

The operators will now start working on uniting their existing developer communities, so developers will be able to go to one place to get their applications distributed instead of having to go through multiple application approval processes.

The community will also start working on a common development standard that should be ready within the next 12 months. The standard will be independent of phone type and operating system, according to the members.

That will allow them to better compete against Apple's App Store or Google's Android Market, which have independent and competing approvals processes tied to their phone or operating system.

"Developers are going to have a lot more access to a lot more customers," said Alex Sinclair, chief technology and strategy officer of the GSMA, at a news conference at the Mobile World Congress in Barcelona.

The Wholesale Applications Community members include: AT&T, China Mobile, Deutsche Telekom, NTT DoCoMo, Orange, Telefónica, Telenor Group, Sprint, Verizon Wireless and Vodafone. Together the operators in the group have about 3 billion subscribers, the GSMA said.

The group has the full backing of the GSMA and the list of supporters will grow in the coming days. "There are several people who are annoyed they couldn't get their name on the list in time," said Sinclair.

Apple is not among those clamoring to be added to the list, but if the company wants to join the group, "it will be welcome," he said.

Just like many phone manufacturers, operators have seen the success of Apple's App Store and want a piece of the pie. Some, including Orange, Verizon and Vodafone, have already launched their own application stores.

Mobile phone manufacturers LG Electronics, Samsung and Sony Ericsson have also voiced their support for the apps community.

The Wholesale Applications Community faces a number of obstacles, according to analysts at CCS Insight.

"Operators are trying to regain control of apps, but have a poor track record with this type of industry consortium," they said in a research note.

"Big challenges remain overcoming inconsistency between standards bodies like JIL and Bondi," the analysts continued, referring to the Joint Innovation Lab created by a group of mobile operators including Vodafone, China Mobile, Softbank and Verizon Wireless, which also has the support of phone manufacturers LG Electronics, Research in Motion, Samsung Electronics and Sharp.

There is no competition between the Wholesale Applications Community and JIL, as all members of JIL are also members of the community, according to Sinclair.

"The last thing we wanted was a Jack versus JIL situation," he said. The groups hope to converge their various specifications within 12 months, he said.

These are some seriously big names, big enough to knock it out of the park if they wanted to.

Re:This doesn't solve fragmentation

[Darkman, Walkin Dude]

It amuses me to no end

Is that you, Lo Pan?

Re:hrmf...

[dave562]

basically, google is lagging badly behind where third parties want to go with android.

That sound eriely familiar to the way they handled Google Apps. I was all gung ho to replace my Exchange server with Google Apps but there were a couple of not so minor little details to be addressed. I tried to get an answer from Google but couldn't get one. Everyone suggested talking to a GAPE partner. I tried to ask the GAPE partners the same questions and their response was, "Google assures us they're working on those features. No, we can't tell you when they will be ready. No, we really can't. Google won't tell us when new features are coming. Here, why don't you try this work around...."

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:Here, let me have a go

[Mr2001]

To date I believe every iPhoneOS device can run the latest version of the OS.

That won't be true for long. iPhone 4.x's pseudo-multitasking feature is only going to be available on the 3GS, not the 3G.

Any loser can develop apps for android. That does two things in my mind. 1) floods the market with garbage 2) opens the door for malware, which we have already seen.

We've seen malware for the iPhone too. A lot of good Apple's policy has done there, huh?

Re:It's a huge issue to app developers, not Google

[Anonymous Coward]

Yeah, because the hardware of the (Motorola) Droid is so different than the iPhone 3GS. Oh wait, no, it's almost exactly the same.

The graphics-intensive, pretty 3D games on the iPhone are mostly horribly sluggish. Not very impressive. The iPad is better, but not amazingly so.

Nobody, nobody targeting mainstream mobile devices is doing 3D stuff beyond what we saw on PCs ten years ago.