The Finally. This is important to read
Why you'll never have the latest version of Android
Why you'll never have the latest version of Android | Android Central
Inside the ‘broken’ Android updates process
If you have an Android phone, chances are it’s not running the most recent version of the OS, 4.1 Jelly Bean. According to Google’s own figures, just 1.2 percent of active devices run the latest version of Android. Some 57.5 percent remain on Android 2.3, a version rapidly approaching its second birthday.
If you were lucky enough to buy a Nexus device -- the right Nexus device -- you might get the latest sweet treat from the Mountain View chocolate factory immediately, or within a few weeks of it being finalized. But for most of the countless millions of active Android devices, it’s quite a different story. They’ll probably never run the latest version of Android, whatever that may be. They’re on ICS if they’re lucky, Gingerbread if they’re not, and by the time they get Jelly Bean we’ll already be singing the praises of Key Lime Pie.
This vicious cycle is a product of Google’s approach to its OS, combined with a mess of other factors including carriers, manufacturers and users’ own expectations. It’s one of the platform’s most significant issues, and one that’s all but impossible to solve. Read on to find out exactly why, as we dissect the Android software update process.
Update anxiety
You buy a phone, you pay your $200, you commit to a 2-year contract with a service provider. It used to be that the manufacturer’s involvement in developing a device ended once it shipped. Instead, as smartphones have become more prevalent, they’re constantly evolving, even after release. New software updates arrive, adding features, changing up the look and feel, and enhancing performance months after purchase. Major updates could even move devices up to a new platform version.
As updates become more common, and consumers become more tech-savvy, there’s an increasing awareness that devices can be updated, and an expectation that they should be updated. With that comes a sort of “update anxiety.” If you’ve dropped by any smartphone message board, such as our own forums or XDA’s, you’ll know what we mean by this. Threads abound asking when ICS, or Jelly Bean, will be available for certain devices. In the event of delayed or even canceled updates, Internet denizens swear they’ll never buy another phone from that manufacturer or carrier again. It’s an entirely negative ownership experience.
While this isn’t representative of the entire user base -- not by far -- it’s an example of how many power users experience Android smartphones. They’re always behind the curve, always waiting on an update, never fully enjoying the product that they’ve bought as they’ve bought it. Part of that is the fault of the tech press -- we’re always focused on what’s new, and that means talking about software that hasn’t yet reached most folks.
There’s also the problem of phones being advertised as “update-ready.” Even now, devices that ship with ICS are being marketed as “upgradeable” to Jelly Bean, in a move that essentially allows manufacturers and carriers to turn the lack of certain software into a feature in its own right. Right from the start, owners are instructed to wait for updates, acutely aware that their new phone has old software. The HTC Rezound was marketed as “ICS-ready” at announcement in November 2011. It received Android 4.0 over-the-air some nine months later, in August 2012. Needless to say, that’s a lot of waiting for an advertised feature.
But updates don’t just happen, and there are valid technical reasons why that new version of Android you’ve been waiting for might take the better part of a year to arrive.
Coding is hard
When a new version of Android is released, it’s put out through the Android Open Source Project (AOSP). AOSP is available for anyone to download, tinker and build Android at their leisure, regardless of whether they’re a major smartphone manufacturer, a custom ROM-maker. But when the code is pushed out, it’s designed to work on Google’s reference devices alone. For Android 4.1 Jelly Bean, it was the Galaxy Nexus’s OMAP 4460 platform and the Nexus 7’s Tegra 3.
Getting a new version of Android up and running on any device running different hardware requires a significant amount of additional work, and even more effort is needed to bring across proprietary code from chipmakers. For example, a Snapdragon S4 device needs Jelly Bean-friendly Qualcomm drivers for the CPU and GPU. The build process the needs to be tailored to the phone’s hardware, and existing customizations need to be worked into the new version of Android without breaking anything.
Even on apparently similar hardware, there’ll often be other proprietary components to work into the mix. For example, the (international) HTC One X is a Tegra 3 device, but includes HTC’s ImageSense chip, something not found on the Nexus 7. It also lays out its internal storage differently, with a separate partition for media. Then there’s the cellular radio firmware to consider. Suddenly, you’ve got a lot of work to do to bring a Tegra 3 device up to Jelly Bean.
Sony explained the entire coding and porting process in great detail in a blog post late last year. It's worth a read if you want to develop a newfound sympathy for the programmers who have to handle these kinds of updates.
The task isn’t limited to code, though. There are often design changes to be considered, especially when updating from Android 2.x to 4.x -- a version change which brought in sweeping UI enhancements throughout. As Sony explained to us at its recent design roundtable in Germany, manufacturers have little warning as to what Google may be working on, so they can’t plan ahead. Admittedly, Google’s trying to change this with its Platform Developer Kit, which gives OEMs early access to certain parts of the framework in new versions of Android. However, the PDK is focused on getting new devices ready for launch, not upgrading old ones. And if the underlying Android design language changes, so too must any customizations that sit on top of it.
Updating an Android device isn't easy, and there's much more to it than dropping in the new code from Google and hoping for the best. It’s a hell of a lot of work, and that’s before you even think about getting it all approved and pushed out onto handsets. If radio changes have been made, the new code must be certified by regional authorities, as well bodies like the Bluetooth SIG and Wifi Alliance. That all takes precious time, and in its blog post last year, Sony identified certification as the most time-consuming part of putting out new software.
The carrier problem
Here’s where we meet the great hate figures of the mobile space -- the carriers. A necessary evil in our connected world, mobile operators have great influence into what goes out on their networks, especially in markets like the U.S. and Japan. That power includes the requirement that manufacturers submit updates for approval before they’re pushed out.
The carrier certification process can be lightning-fast or arduously long-winded. Minor updates, particularly on GSM carriers outside of the U.S., are often subject to quick approval. A good example is Three UK’s approval of a bug fix patch for the HTC One S. This passed certification in a couple of days, as only minor changes had been made, and the carrier was satisfied nothing in there was going to break its network.
At the other end of the scale are major updates on some of the U.S. carriers. We’re going to pick on the Verizon Galaxy Nexus here, but there are plenty of other examples on rival networks. Big Red’s Gnex took upwards of two months to pass certification for its Android 4.0.4 update, and Jelly Bean for the Nexus, completed in July, still isn’t out. It’s impossible to know exactly why things have been held up, or who, if anyone, is to blame. But it’s an example of how extra weeks of waiting can be added if issues crop up during the certification process.
Carriers are generally slow moving, and they’ll always err on the side of caution. They also have limited resources when it comes to certifying smartphone software, and the priority, naturally, will always be given to approving new devices ready to go on sale. That’s how you make money. And a similar attitude prevails at some OEMs, too. If a phone hasn’t sold well, or it's a budget model, it might just not be worth the time and money to develop and certify an update. Smartphone manufacturers are businesses, after all.
Android versus Android-based
But these are Android phones, right? Why is it so difficult to keep Android phones on the latest software, especially when the likes of iOS and Windows Phone seem to manage a much quicker, more elegant upgrade process?
The answer is variety. Apple has no more than three current phones at a time, making the task of syncronizing updates across its devices far easier. The iPhone range also has less internal variety from one model to the next. What’s more, Apple’s tight control over every aspect of hardware and software means it can easily anticipate future software versions in a way Android phone makers can’t.
As for Microsoft, it’s almost as controlling as Apple. Its phones are limited to Qualcomm Snapdragon CPUs and a fixed range of display resolutions. Certain areas of the OS are off-limits even to OEMs, and there are strict requirements for Windows Phones, such as particular button setups and memory quotas. Windows Phone OEMs are also extremely limited in the changes they can make to the UI. All of these factors make it easier to push out updates across seemingly diverse hardware from different manufacturers.
We should also point out that Android phones, as we tend to think of them, aren’t just Android phones. They’re Android-based phones.
A few months back, Google’s Vic Gundotra made a post on Google+, singing the praises of his new Nexus 7 tablet, along with an attached photo. When followers asked him what he used to take the picture, he replied in very precise, deliberate language -- it was taken on his “Android-based Galaxy S3.” Gundotra’s wording illuminates a crucial distinction between Nexus and “Google Experience” devices, and the Samsung, HTC and Motorola-branded phones that dominate the walls of most stores. Android is what’s released by Google. Once manufacturers get hold of it, the end product is Android-based. There’s stuff in there that Google doesn’t directly control, meaning it’s no longer just “Android.”
The HTC One X is an Android-based HTC Sense phone. The Galaxy S3 is an Android-based Samsung TouchWiz phone. Though they're compatible with Android and share a common feature set, they're different to the operating system delivered by the folks at Mountain View.
The perils of v​ariety
Being an open-source OS, OEMs are free to do pretty much whatever they want with Android. The only real limiting factor is the Android Compatibility Test Suite -- a set of testing programs designed to ensure they haven’t messed with the framework in a way that breaks third-party apps. Phones must pass this test in order to get the Google seal of approval. But there’s no provision in the CTS for making sure a manufacturer-customized build of Android is easy to update, and as such there are no guarantees about update timings.
You might say that’s a bad thing, especially if you’re a fan of vanilla Android. If Microsoft can force manufacturers not to mess with the Windows Phone UI, why doesn’t Google do the same for Android? Well if it did, Android would become a whole lot less attractive to Google’s real customers -- carriers and device manufacturers. They want to slather Android with their own software and design language to differentiate themselves in the crowded and competitive mobile market. We're they unable to do this, they simply wouldn’t make as many Android phones, and consequently customers wouldn’t buy as many Android phones.
Fewer Android phones would mean fewer ad clicks in Google search, and fewer mobile users funneled into Google’s app and content ecosystems. Google doesn’t want there to be fewer Android phones. Google wants hundreds of millions of Android phones, and to reach that goal it must open Android up to customization.
As a result, Google, as a platform holder, is powerless to force updates onto “Android-based” handsets. Its OS’s vast market share relies on having a multitude of devices on sale, and that in turn leads to endless variety in hardware specifications, manufacturer customizations and carrier requirements. It’s that variety which makes fast, frequent updates for devices such an utterly impossible task, for the technical reasons we’ve already discussed. Simply put, there’s no way Android as a whole can have fast updates and a large market share. It’s precluded by the nature of the platform, and more importantly, Android’s place in Google’s business strategy.
Unfortunately, despite token offerings like Motorola’s 100 bucks if your phone doesn’t get Jelly Bean, and the ill-fated Android Update Alliance, things show no sign of changing.
) but it really is a great app: Free|Pay
