Justifying Android’s “Slow” Update Roll-outs, Redux: Who’s Really to Blame?

In my previous article, I gave a few points explaining why I think Android takes more flak than it really needs to in terms of the time it takes to receive updates on its devices. However, after that article was published, I realized I still had a great deal more to say on the topic. In addition, a few things were pointed out to me that I would like to address.

The most common target I have seen people painting is one that lies on Google. They blame Google for the wait to get the latest Android version. They blame Google when they find out their device won’t be getting the next version of Android. They blame Google when it chooses not to operate as Apple does.

I guess this means I have to come right out and say it: I do not believe Google is at fault for a) the slow updates to Android devices, nor b) the issue of fragmentation that results from them. Why, then, do people blame Google? Perhaps it is because people are impatient and cannot stand the fact that they have to wait a little while for a freshly cooked Android release to hit their device. Perhaps it is because people are ignorant and choose to act impatient rather than understand what is really going on under the hood. There is also the possibility, of course, that a person sorely has it out for Google and/or Android, jumping at any slight chance they see to try to take a jab at them.

Despite why it is that people choose to pick on Google, there are plenty of reasons to argue why they are being outright silly. Especially so after a few particular things I stumbled across after publishing my last article that provide plenty of logical explanations for just what is going on in the Android ecosystem.

First off, here is an excellent post from Sony itself about the process that a manufacturer goes through when a new Android release drops into the Android Open Source Project (AOSP). The post describes the path manufacturers take, in detail, when porting Android over to a specific device. When the latest version of Android becomes available in AOSP, manufacturers and hobbyist developers alike take off in getting a build running on their target device. Here’s one of the first arguments I have heard from quite a few people, who wonder why developers who are working on a port in their free time and often with little know-how of the device’s inner workings are able to push out an unofficial working build much faster than the manufacturer that built the phone. As mentioned in the linked blog post, manufacturers are required to go through a lengthy certification process with nearly every change they make, whereas the CyanogenMod team, for instance, suffers no such setback. Be glad they go through this certification process, however, as it ensures the device you are using is up to code both health-wise and productivity-wise.

Second, Google employee and AOSP maintainer Jean-Baptiste Queru began an insightful thread on Google+ on Thursday, the same day my previous article was published. One of the first things he mentioned was how impressed he was with Sony to see Ice Cream Sandwich on its devices so soon:

It took Sony only about five months to ship this after I released the code in the Android Open Source Project at the very end of last year. This is actually a very reasonable time, since under the hood Ice Cream Sandwich is quite different from Honeycomb (and upgrades from Gingerbread are likely to take longer as those differences are huge).

I have dug around in (and contributed to) the Android source code before, so I can assure you that there are tons of moving pieces that make Android operate.

But the impatient still ask why this porting process can’t be done sooner. One possible solution that has been proposed before suggests that Google makes its internal development process open so that, as it adds new features for the next Android delicacy, manufacturers can continually merge them into their own builds.

This presents many more problems than most would think, though. If the development process was entirely opened, manufacturers might release half-baked features to the public before they are ready for prime time, resulting in a lackluster experience for everyone. In addition, the fragmentation that exists right now would increase dramatically, as you would see some devices shipping with certain framework features and other devices shipping with different features altogether. Finally, assuming manufacturers play nice and wait for Google to officially ship the next release, opening the source code before that occurs could result in competing operating systems (e.g., iOS and Windows Phone) stealing features and shipping them to the public before Android can, claiming them as their own (as far as the general public knows, anyway).

One thing I can agree on, however, is that manufacturers that apply custom skins and add in additional features to the framework slow their release cycle down tremendously. I understand the need to differentiate, but is that really worth the customers’ diminishing faith that they will see updates in a reasonable amount of time? If they truly wanted to help out, they would contribute their ideas to the AOSP so that every Android user can enjoy them, much like Sony does, which nets them a shorter porting process as JBQ points out:

Since Sony has been contributing a lot to the Android Open Source Project, [it has] fewer changes that [it needs] to maintain on [its] own: those changes … are already there when the source code is first released. That’s probably one of the reasons why [it] could get done faster: the work [it] did preparing those contributions gave [it] a head start. I don’t think that any other manufacturer has been contributing nearly as much as Sony did, so everyone else is now going to have to play catch-up.

In other words, manufacturers should share their software love with the entire Android ecosystem while differentiating themselves through what they do best: the hardware and design of the device that wraps it. Why don’t they contribute more code to AOSP, though? JBQ once again provides a clue:

Licensing issues potentially get in the way: manufacturers have access to a lot of information from their suppliers that can’t be used in open source systems, so they need to navigate between all those restrictions to find what they can open source. Since Android has always been meant to be open sourced, Google has been paying very close attention to those issues since the very beginning.

What else can be done, then? If the future really is open source, then perhaps it is up to the chipset designers and low-level hardware developers like Qualcomm and Nvidia to cooperate more with the community, at the very least providing reference documentation for their driver implementations and the like. Carriers too, need to do this, as CDMA networks like Verizon’s require proprietary binaries to be bundled with the system before a device can access the network.

The bulk of the blame, I believe, should fall on the carriers. Even after a manufacturer gets its changes certified, the build must then be approved by the carriers that ship the device. Even Google has encountered this issue with its own line of Nexus devices:

The part that blows my mind is that some variants of the Google-engineered flagship devices still haven’t received Ice Cream Sandwich (or are stuck with older versions of Ice Cream Sandwich) because of delays introduced by operator approvals. I’m very glad that Google is back in the business of selling phones directly without any middlemen to interfere, and I’ll be even happier when I see that program expanded to more countries.

Perhaps manufacturers should duplicate Google’s initiative and sell their devices themselves, rather than letting the carriers choose essentially which devices go to market and which updates roll out to the consumer. Save from whole updates, carriers are also picky about what applications appear in the Play Store, preventing many Android users from enjoying the whole host of apps available to the rest of the ecosystem. For instance, Verizon blocks Google Wallet (a Google app, no less!) from appearing in the Play Store on its subsidized devices because it is working on its own system. Even worse, that system “needs to be integrated into a new, secure and proprietary hardware element in [Verizon’s] phones,” as the Wall Street Journal reported last December. Google really had no choice but to let Verizon make these controlling decisions, as I explain next, carriers have all the power in the US, and Google can’t afford to lose out on the market Verizon offers with its subscriber base. If Google included Wallet anyway, Verizon might have dumped the Galaxy Nexus from its selection of smartphones, essentially leaving Google without a US market to sell into (that is, even with all the people who went with the unlocked Galaxy Nexus on AT&T and T-Mobile, Verizon is still the largest carrier in the US).

Unfortunately, with the stranglehold carriers have on consumers in the United States with their tricks of subsidized phones with a two-year contract, it might be hard for manufacturers (as well as Google) to gain traction with the “lone wolf” approach. However, Google’s act of dropping the price of the unlocked GSM Galaxy Nexus to a mere $399.00 in the Play Store is a great move on its part.

So, as I have explained, there are many players beside Google in the Android game that have a much stronger impact on updates and fragmentation than Google does. I’m afraid to say that Google is trying its hardest to help ease the issue, but until some big changes happen (with carriers in the US market and manufacturers on a global scale, specifically), we won’t see any major improvement at all. There are a few things Google can continue to do, however:

  • Sell unlocked devices itself, separate from the carrier, in hopes that other manufacturers will follow the example
  • Push manufacturers and hardware developers to contribute back to the AOSP in the form of framework patches and open source driver implementations
  • Name future Android releases after even more delicious treats, securing the sweet-tooth vote

And I think that’s the best I’ve got, or at least the best I’m going to be able to stab this particular issue. Please feel free to leave your opinions and comments below; perhaps you’ll stumble across a larger point that I just missed completely (I do that, sometimes). Also, be sure to read Jean-Babtiste Queru’s Google+ post that I mentioned above, including the comments that follow it, as he provides more insight than just what I have mentioned here.

Article Written by

  • http://ARMdevices.net/ Charbax

    99% of the million Android apps work on 99% of the Android devices in use today. There is no fragmentation in terms of compatibility. Only Chrome for Android doesn’t work on older Android versions, but it’s Beta.

    • http://eddieringle.com Eddie Ringle

      Agreed. Google has done an excellent job at making sure the applications themselves are compatible across Android versions. However, it is when certain features of newer Android systems (e.g. Face Unlock, Holo, etc.) are touted that people begin to feel left out when they learn they can’t have those yet because their device isn’t receiving an update. Therefore, they call the entire ecosystem fragmented.

      • http://ARMdevices.net/ Charbax

        I don’t think 90% of Android consumers even know about those features of ICS you talk about (Face unlock, Holo etc), I don’t even know what you mean by Holo. The Android fragmentation talk is only an issue to tech bloggers and tech experts that read Engadget/Gizmodo every day. 95% of consumers don’t care. But sure enough ICS is absolutely awesome, not just in terms of UI innovations, but in terms of hardware acceleration that basically accelerates everything and uses the GPU to accelerate stuff, improve multi-tasking, improve the possibilities of the web browser as shown in Chrome for Android Beta.

        But that I believe does not mean fragmentation, fragmentation is a definition of incompatibility. Where things are not backwards compatible, not forward compatible. I don’t think that is true about Android. Since 2008, Android has carefully been engineered to scale to any screen size, any screen resolution, any DPI, any screen aspect ratio, also scale to any type of touch screens (capacitive, resistive, IR optical.. etc) and for those to be compatible with any sensors etc. 95% of Android apps work perfectly fine on every tablet size. Usually it’s only the poorly written apps that don’t scale correctly to other screen sizes, resolutions, such as tablets. Correctly written Android apps work perfectly on every Android device. Even apps written using the Android 1.6 Donut SDK released in 2009 work perfectly on Android tablets today.

        As for adoption of ICS, pretty much every new Android device being shown at trade shows since CES, all run ICS at launch. Pretty much more than 90% of Android devices in use sold in 2011 are getting the ICS update now or very soon. Also a large chunk, maybe upwards 90% of the Android devices still in use sold during 2010 are also getting the ICS update. It’s really not much to do with all those custom Android UIs, it’s mostly to do with the work to optimize ICS for each of the older ARM Processor platforms such as each of the Dual-core processors of 2011, each of the Single-core processors of 2010 and 2011, each have slightly different RAM and GPU configurations, the engineers at Google and each of the Chip providers simply have had to work hard on optimizing and adapting ICS for each of those. It’s normal that takes a few months.

        • http://eddieringle.com Eddie Ringle

          Again, I completely agree. When both my mom and I had our T-Mobile G2s (HTC Vision) but I was running CM9 while she was stuck on Gingerbread, she really didn’t know about any ICS features unless I reminded her I had them and she didn’t. Even then, she’d eventually forget and continue to enjoy her phone. Another instance of this, I was playing with Face Unlock at school today, but I had to explain it to my friends that it was a feature in ICS. Most hadn’t even seen it before. So I agree 100% that fragmentation is most definitely more of an issue with the tech-savvy consumer versus the general population of smartphone users.

          As for your point about the advancements in ARM architecture, I hint at this when I talk about the porting process manufacturers go through when porting new Android versions to their devices. I’d rather wait a few months longer for a OS that squeezed every drop it could out of the hardware than one that was generalized to a “one size fits all” scheme.

          • http://ARMdevices.net/ Charbax

            I think we tech-savvy consumers have had the option to simply buy the Galaxy Nexus since ICS has been open sourced around November/December last year. And since then most of the newest devices from HTC, Huawei, etc seem to come with ICS pre-installed. And if they don’t the ICS update is always promised for 1-2-3 months after the release. Because it’s normal for example for the Sony Xperia S to need its couple or three months to get ICS optimized to its Qualcomm processor and Adreno GPU, which is not same as Galaxy Nexus OMAP4460 processor and SGX GPU. And by the time Tegra3 got all the ICS optimizations, now the HTC and LG phones with Tegra3 are coming out. As for SGS3 using newest Exynos 4412 also now comes out with ICS pre-installed as older Exynos 4210 devices released last year are all getting ICS firmware update about now also.. Those are each of the 4 major ARM chip providers, Texas Instruments (Galaxy Nexus), Qualcomm (Sony), Nvidia (HTC, LG) and Samsung (SGS3 and last years Samsung devices), and a mix among them, those device makers use different chip providers, Qualcomm has many many skews on different devices by dozens of makers, so sure enough slowly but surely all the devices are getting ICS, and I don’t believe ICS’s market penetration is going to look any less grandiose than Gingerbread has been until ICS has been available. Compared to when Gingerbread took over 70% of Android install base, by the time ICS has the same 70% reach there will be more than double as many Android phones sold on the market. So with each new Android version, the scale of work being done to upgrade every device is much larger, but that is how I think Android was awesomely architected from the start, to support that kind of scale of growth that I think even Google had no idea Android would be as successful as it is now.

  • Allan

    Carriers do not control all phones, they sure do not control Apple

  • brentwhopkins

    Android is no more fragmented than any other platform. And, frankly, anyone who buys a device based on future expectations of updates rather than as-is functionality, is indulging in wishful thinking at best.