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.