HTC details how carriers, chipset makers stall & block Android OS updates
Taiwanese smartphone maker HTC has shed light on the complex route Android updates must navigate before hitting customer devices, helping to explain why operating system updates take some time to arrive, and how, for some device owners, such updates never even arrive at all.

HTC has detailed the circuitous 12-step process as part of their Software Update status page, which tracks the company's progress in rolling out the latest version of Android to their flagship handsets. A monstrous 10,000-pixel-tall infographic walks readers the procedure, beginning when Google notifies the carriers of what they will include in Android's next version bump.
Before the update's public announcement, Google releases a "Platform Development Kit," or PDK, to its manufacturing partners. The PDK is essentially the hardware equivalent of a software SDK --?it provides the tools necessary for device manufacturers to build Android-compatible hardware.
The update's source code is not released until after Google makes their public announcement, when it is shipped off to both handset manufacturers, like HTC, and chipset makers, such as Qualcomm, for evaluation. Both parties must agree to support the update before it can move forward, the first of several points at which the process can be derailed.
Chipset makers that elect to move forward with the update then begin the process of creating and optimizing new drivers for their hardware. It is up to each manufacturer to decide which chipsets will be targeted -- devices using chipsets that do not make the cut, no matter their age, will be unable to run the newest Android version.
Until this point, the process is the same for all three classes of Android devices made by HTC --?carrier devices, customized for and sold by carriers like Verizon Wireless; unlocked and developer edition devices, sold directly from HTC to customers; and Google Play edition devices, which run versions of Android unadulterated with carrier or manufacturer customizations. Once the chipset makers have had their say, however, each device follows a slightly different path.
For carrier and developer devices, the handset manufacturer can begin merging the Android and chipset updates with their existing code base. In HTC's case, this means integrating their HTC Sense user interface customizations.
Carriers then become involved, dictating which special applications, services, and carrier-specific modifications will need to be made. Google Play and developer edition devices are not subject to the carriers' whims, one reason why those handsets have already received their Android 4.4 "KitKat" updates while carrier phones have been forced to wait until 2014.
After internal testing, the updates are sent out for certification by carriers, regulatory bodies, and Google itself. Any of these players can delay the update and force changes to be made, but Google maintains final approval - without Mountain View's OK, the update will never see the light of day.
Apple, in comparison, faces a single stakeholder when it comes to iOS updates: themselves. They need only regulatory approval and technical certification from carriers --?Apple famously released their cross-platform messaging service, iMessage, without consulting any of their carrier partners.
The effects of this dichotomy are illustrated by the latest version distribution statistics. Cupertino's newest operating system, iOS 7, now runs on more than three-quarters of all iOS devices, while Android 4.4 "KitKat" is found on a relatively miniscule 1.1 percent of devices, according to Google's developer dashboard.

HTC has detailed the circuitous 12-step process as part of their Software Update status page, which tracks the company's progress in rolling out the latest version of Android to their flagship handsets. A monstrous 10,000-pixel-tall infographic walks readers the procedure, beginning when Google notifies the carriers of what they will include in Android's next version bump.
Before the update's public announcement, Google releases a "Platform Development Kit," or PDK, to its manufacturing partners. The PDK is essentially the hardware equivalent of a software SDK --?it provides the tools necessary for device manufacturers to build Android-compatible hardware.
The update's source code is not released until after Google makes their public announcement, when it is shipped off to both handset manufacturers, like HTC, and chipset makers, such as Qualcomm, for evaluation. Both parties must agree to support the update before it can move forward, the first of several points at which the process can be derailed.
No less than four stakeholders must agree in order for an Android update to run the gauntlet and make it to customer devices.
Chipset makers that elect to move forward with the update then begin the process of creating and optimizing new drivers for their hardware. It is up to each manufacturer to decide which chipsets will be targeted -- devices using chipsets that do not make the cut, no matter their age, will be unable to run the newest Android version.
Until this point, the process is the same for all three classes of Android devices made by HTC --?carrier devices, customized for and sold by carriers like Verizon Wireless; unlocked and developer edition devices, sold directly from HTC to customers; and Google Play edition devices, which run versions of Android unadulterated with carrier or manufacturer customizations. Once the chipset makers have had their say, however, each device follows a slightly different path.
For carrier and developer devices, the handset manufacturer can begin merging the Android and chipset updates with their existing code base. In HTC's case, this means integrating their HTC Sense user interface customizations.
Carriers then become involved, dictating which special applications, services, and carrier-specific modifications will need to be made. Google Play and developer edition devices are not subject to the carriers' whims, one reason why those handsets have already received their Android 4.4 "KitKat" updates while carrier phones have been forced to wait until 2014.
After internal testing, the updates are sent out for certification by carriers, regulatory bodies, and Google itself. Any of these players can delay the update and force changes to be made, but Google maintains final approval - without Mountain View's OK, the update will never see the light of day.
Apple, in comparison, faces a single stakeholder when it comes to iOS updates: themselves. They need only regulatory approval and technical certification from carriers --?Apple famously released their cross-platform messaging service, iMessage, without consulting any of their carrier partners.
The effects of this dichotomy are illustrated by the latest version distribution statistics. Cupertino's newest operating system, iOS 7, now runs on more than three-quarters of all iOS devices, while Android 4.4 "KitKat" is found on a relatively miniscule 1.1 percent of devices, according to Google's developer dashboard.
Comments
http://gigaom.com/2013/12/20/as-moto-g-gets-kitkat-motorola-becomes-a-nexus-maker-for-the-masses/
Google is likely working on a true mobile OS, unlike Android, that does not piggyback on Linux. It'll probably run all current apps in a virtualization mode similar to when OS9 ran on OSX, or how Android runs on top of Linux.
It's inevitable, it's also the only way they will be able to clean up their act.
Observation:
Appleinsider, Google has managed to remove from Wikipedia references to the fact that the first Android demo looked liked BB and instead implied that Android, as it's known today, was developed in 2005. They also removed references to the fact that Android is a piggyback OS, much like Flash to a web-browser. The whole Wikipedia Android page reads like a commercial of heroism and conquest. Who has the Wiki credentials and good English to set some facts straight?
http://en.wikipedia.org/wiki/Android_(operating_system)
I'm not certain how accurate the process description is. Motorola has rolled out KitKat 4.4.2 in record time to it's MotoX and MotoG smartphones. Just three weeks after the formal announcement of 4.4 in the case of the MotoX (and Verizon of all carriers!). Maybe if some if some of the vendors didn't skin their devices so aggressively the updates could get completed quicker. Of course for some of the smaller licensees they may not care if their phone gets updated or not.
http://gigaom.com/2013/12/20/as-moto-g-gets-kitkat-motorola-becomes-a-nexus-maker-for-the-masses/
Motorola IS Google.. They got to bypass much of the process. They seem to be treating the update process like a Nexus for the most part.
Remember, Motorola has also been Verizon's pet for years, allowing Verizon to combat the iPhone with Android for all those years they didn't have an iPhone. Motorola has pushed DRIOD moniker on Verizon for some time and they likely know how to get through Verizon's BS approval process much quicker than other players..
Sounds like one mighty cluster-frell.
That is right, my dear Crichton.
The carriers are holding back advancement. If it wasn't for Apple basically telling AT&T to sit down and shut up when the iPhone was launched, we'd still be staring at screenfulls of AT&T, Verizon, Sprint, et al, crapware on our screens and logos on our phones instead of the simple Apple logo on the back. Apple's iMassage would never have been launched because of the threat to texting and texting plans.
Unfortunately, they are trying to get that control back and won't stop until some real competition comes along.
Google owns Motorolla so of course they will be updated.
Bottom line is these phone companies need to make their own OS and stop bitching about Android. They are getting Android free so they should shut the fuk up or spend BILLIONS like Apple developing an OS.
As has been demonstrated by Windows OS, Android OS, Chrome OS, Mozilla OS, and Tizon, developing an OS, let alone a lightweight OS, is no easy feat. Throwing money at it doesn't make it better or finish sooner. It will take a good 4 years for version 1.0, which may or may not have Copy Paste.
They could only "bypass much of the process" if the carrier's allowed it. If they'll do so for Moto why not for HTC or Samsung? I personally think it has as much to do with how committed the manufacturer is to updates and the work they have to do to get it done. Skins don't help in that regard.
This is true, but those scenarios cannot be compared: support for less than 10 (very similar) devices versus support for 4000+ (very different) devices.
While you need a specific iOS version to run certain apps or have a certain feature, Android has a different approach: most internal features are updated on all devices (if registered in Google Play) through Google Play Services automatic update (a sort of system library) and apps can be developed from the beginning with the multi-os-version support library (actually not easy to use by developers). So, even if Android versions are actually fragmented, the only real fragmentation problem is the 2.3.x (Gingerbread) support, because basically it forces developers to develop two apps. Apart from that, almost all apps for 4.0 to 4.4 are the same app (no fragmentation on developer side).
Im my opinion, if you want to compare quality of support in a similar scenario, you should compare "iOS devices support" with "Nexus devices support". In my experience frequency of updates is quite similar. The only difference is that after two years Apple devices still receives updated iOS, but without most new features and with a very very bad user experience (4S with iOS7 is snappy, but my iPad 1 with iOS 5.1 is barely usable).
I'm not certain how accurate the process description is. Motorola has rolled out KitKat 4.4.2 in record time to it's MotoX and MotoG smartphones. Just three weeks after the formal announcement of 4.4 in the case of the MotoX (and Verizon of all carriers!). Maybe if some if some of the vendors didn't skin their devices so aggressively the updates could get completed quicker. Of course for some of the smaller licensees they may not care if their phone gets updated or not.
http://gigaom.com/2013/12/20/as-moto-g-gets-kitkat-motorola-becomes-a-nexus-maker-for-the-masses/
Lots also has to do with what chipsets you have. Lack of a BSP can kill an update so choosing the right HW partners is key. The skinning is just a small piece.
I would imagine that updating libraries may be good for the later apps, but I'd think some older apps might get wonky.
They could only "bypass much of the process" if the carrier's allowed it. If they'll do so for Moto why not for HTC or Samsung? I personally think it has as much to do with how committed the manufacturer is to updates and the work they have to do to get it done. Skins don't help in that regard.
I don't think you are looking at this quite correctly. In the case of Motorola the process basically reduces down to what Apple has. In this singular case the OS creator/vendor is the same as the hardware creator/vendor. In fact, your point supports the contention that Android updates are stuck in a mess, and the only one that seems to come out with timely updates is the only one that cuts out most of the steps because they are the ones that make the OS.
I'd take one of those from Siri any day
"Just three weeks." Google owns Moto so of course they would have advanced knowledge.
Btw, record time is immediate as with iOS.
What HTC provided was a dispassionate account of the process.
'stall' and 'block' are loaded terms, introduced through the usual creeping dishonesty which impregnates this site's reporting.
...
'stall' and 'block' are loaded terms, introduced through the usual creeping dishonesty which impregnates this site's reporting.
^^ wow!
Do you really think that the market would support a multitude of mobile OSs? Would developers make apps for 4-5 different OSs? That's an unreasonable suggestion, and one that would most certainly spell doom for many involved.
That's not true, this time around the GNex was left out only because of it's processor's incapability. If I remember correctly the GNex has a Texas Instruments processor that's no longer being used in any other devices.