We’ve all heard the lamentations of the Android faithful yearning for updates. It’s all the fault of the custom skins, and the unnecessary changes made to Android that makes our updates late. Well, according to a pair of blog posts from Sony Ericsson and Motorola, that’s not so much the case. On their respective company blogs, the OEMs had a chat about what the Ice Cream Sandwich (ICS) upgrade path is going to look like.
If this information is to be believed, the parts of the process that we think take the longest, aren’t the real problem. In fact, Google might be more at fault than we ever knew.
Unless an OEM is the preferred device partner of the Nexus program, the first time it gets a real look at the Android source code is when Google adds it to the Android open Source Project (AOSP). This is also when modders, curious onlookers, and the man on the street can get access. It’s obviously not a simple matter of taking the code, and loading it on devices. Even if the OEM was not going to change the interface, this wouldn’t be doable.
Since Android does not have a set hardware spec, everyone has different chips. The Hardware Abstraction Layer (HAL) is the part of the Android software that allows direct access to the device components. The first place that Google is delaying OEMs is with this hardware layer included with Android.
Android is usually built on one device, so the HAL is designed to work with one hardware platform out of the box, so to speak. This time Google is using TI OMAP in the Galaxy Nexus. Sony Ericsson is using Qualcomm Snapdragon parts in its phones, so the HAL needs to be modified immediately. All of Sony Ericsson’s 2011 phones are slated for the update to Android 4.0.
Motorola is in a slightly different situation. It uses a few different types of hardware in its 2011 phones, but the more recent additions to the lineup are based on OMAP. Conveniently, these newer phones, like the Droid Bionic, Razr, and Xoom 2 tablets are the devices Moto has confirmed it will update. Phones built on Nvidia’s Tegra 2 chip haven’t been given the official blessing.
The next step in the process is where all those UI flourishes and altered home screen come into play. An OEM will take the mostly stock code and add in its modifications; things like Sense, Blur, or TouchWiz are bound to the pure Android bits. Some more innocuous patches could also be added, and Sony Ericsson even contributes some of that back to the AOSP code.
These early software builds are then tested by the OEM to root out the obvious bugs. If a phone is carrier-branded, the carrier also get to take a crack at it. The carrier isn’t so much interested in Android bugs, but more in the network performance and integration of its software and services.
Before users can get the software on their devices, the OEM has to jump through some regulatory hurdles. If the device is not new, most of the process is bypassed, but if the characteristics of any wireless component have changed, that needs to be re-tested. For example, if the Android update includes a new radio image, and most do, that’s going to need to be re-certified. In a similar vein, the OEM has to make sure that standards bodies accept that the software keeps things like Wi-Fi and Bluetooth wuthin spec. The finished software is then pushed out to users, usually in small batches at first.
The Real Time Sink: Certification
So what’s the most time consuming part of this whole endeavor? We’ve always though it would be the process of designing the update, which is why Android skins have been seen as the real issue. According to Sony Ericsson, it’s actually the process of having an update certified by regulators that takes the most time.
Each phone that gets an update does of course require development time, but when devices have similar innards, much of the work can be done in one shot. But still, each and every device needs to be passed through regulatory agencies all over again. It’s not as long or as drawn out as a device’s original certification will have been, but for large updates like ICS that alters the behavior of most wireless components, re-certification really will take some time.
Going back to the beginning, though, hardware differences still cause some hefty delays. When an OEM uses a variety of chassis designs, it makes it less likely that all its devices will see updates. We already have the example of Motorola giving preferential treatment to devices on the reference platform, and others could follow. The HAL is very low-level in the system, and changing it dramatically can require quite a lot of additional work.
What Can Be Changed
One short-term change that Google could make itself is to be more open with OEM partners about upcoming code drops. A certified Android partner and member of the Open Handset Alliance should have better access to the development process than enthusiast modders. There’s no reason that a company that has a phone to update shouldn’t get a little head start.
This would not need to cheapen the Nexus program; other OEMs could only be given access to parts of the code, or only get minimal lead time over the open source community. It could be said that this is a less open way to develop Android, but Google already keeps the code private until it is deposited in AOSP anyway. This could let OEMs begin work on the more difficult parts of the development process like changing the HAL.
Beyond Google’s control, but still something that could likely do with some streamlining, is the regulatory process. It is very surprising that this is the most time-consuming part of the update process for some OEMs. There are good reasons for regulators to do wireless device testing, but maybe a new Bluetooth stack isn’t cause to re-certify the device.
It’s telling to get this inside look at Android updates from two of the largest makers of devices. The development process isn’t an overnight deal, but the degree to which regulatory matters slow the process is unexpectedly great. Android has worked well so far while being rather disjointed, so we don’t expect Google up tighten the hardware spec to make things easier. Perhaps better code access and more common sense regulatory processes can reduce the months-long waits most users suffer.