Is there anything Google can do to solve the problem of slow Android updates?

Google is getting ready to roll out its very first Jelly Bean (Android 4.1) device, the Nexus 7 tablet, and while that’s exciting news, it’s also sobering for scores of Android users still waiting to unwrap Ice Cream Sandwich (Android 4.0.x). The numbers in Google’s own Dashboard for developers tell the story in disappointing detail, but they don’t pinpoint the problem.

What they reveal are cold, hard facts — such as, just 7.1% of active Android users are currently sinking their teeth into ICS, even though it was released more than eight months ago. Honeycomb (Android 3.x) is looking more and more like a stopgap solution with a less than 3% market share, while the vast majority — nearly two-thirds —  of Android users are still rocking Gingerbread (Android 2.3.x). After that, Froyo (Android 2.2) accounts for 19.1%, followed by Eclair (Android 2.1) at 5.2%, and Donut (Android 1.6) and Cupcake (Android 1.5) combining for less than 1%.

The problem here isn’t that fragmentation exists in the Android camp, rather the real issue is that OS updates are slow to roll out to the masses (fragmentation is a partial byproduct). There’s plenty of blame to go around, some of it valid, and some of it misinformed. Falling into the latter category is a mini rant by AT&T CEO Randall Stephenson, in which he claims that “Google determines what platform gets the newest releases and when,” and that it’s “a negotiated arrangement.” In reality, Google drops the source code for new Android builds at the Android Open Source Project the moment the first device based on it launches.

Device manufacturers often apply their own UI overlays to Android, adding another layer of complexity to certifying OS updates.

Popular opinion is that fancy user interface (UI) overlays like Blur (Motorola) and TouchWiz (Samsung) are to blame, but that isn’t necessarily the case. Prior to being scooped up by Google, Motorola Mobility vice president and general manager, Christy Wyatt, said the software is the easy part, and that testing Android builds on various chipsets and carriers is the real culprit. Her point is underscored by Sony’s rare and detailed inside look at exactly what’s involved in porting a source code release to a bona fide software upgrade.

Unfortunately, there aren’t any winners when playing the blame game, and if Google’s going to solve the problem, it has to figure out if a solution even exists, and whether or not it cares to implement it.

One way Google could solve the problem is by changing the culture of Android by encouraging manufacturers to charge for a fee for Android updates. We already looked at reasons why this could work, and as many readers noted, there are significant roadblocks, one of them being that it would drive consumers to other platforms.

An alternative would be for Google to take the reins and handle all updates for all devices. It has the manpower and resources to take on that kind of Herculean task, but does it have the desire? Probably not. Jean-Baptiste Queru, technical lead on the Android Open Source Project (AOSP), considered the five months it took for Sony to ship ICS on its Tablet S device a “very reasonable time, since under the hood Ice Cream Sandwich is quite different from Honeycomb,” according to his post on Google+. If five months qualifies as “very reasonable,” then what does eight months, which is where we’re at today, qualify as? What about 10 months, or a year? At what point do these slow rollouts become “unreasonable?”

Figuring out a reasonable time frame for Android upgrades is just one of the many challenges Google would face if it took hold of the reins and issued updates for all software. Trying to prioritize specific devices, manufacturers, and wireless carriers is an awful lot for Google to try and juggle, and on top of it all, custom UIs would probably need to be tossed out the window. It’s difficult to imagine device makers being on board with that idea.

Apple doesn’t have this problem because it builds its own hardware, and neither does Microsoft, which requires Windows Phone makers follow a specific hardware blueprint.

This brings things full circle to the original question of what Google can do to solve the problem of slow Android rollouts, and the answer might be “nothing.” As long as Android’s stock keeps rising, you can expect Google to do exactly that, though not because it doesn’t care. It’s just that no one has yet come up with a feasible solution that will appease device makers, wireless carriers, and consumers in one fell swoop.

moderntrick.blogspot.com