Why OEMs need months to deliver Android updates to your phone

Share This article

For Android OEMs, getting a new version of the operating system onto devices can be a multi-layered endeavor fraught with peril. It’s not as easy as picking up the code from Google one afternoon, and pushing updates out the next. There is a significant amount of software development, testing, and certification to go through. Both Sony Ericsson and Motorola have released some details on the process, giving us a look at how Android gets from Google, to OEMs, to carriers, and ultimately to you.

The code drops

The whole process starts when Google drops the open source code into the Android Open Source Project (AOSP) repository. This usually happens around the time that the new Google experience device (that’s the Galaxy Nexus this time) is released. OEMs have to take that code, and integrate it with the in-house code trees to begin work. The only exception to this is the hardware partner for the official Google experience device, which gets the code early and works closely with Google. For the last two years, that was Samsung, and before that it was HTC.
The first order of business according to both companies is to start optimizing the Hardware Abstraction Layer (HAL). This is the software layer in Android that gives the software access to device hardware. In the case of Android 4.0 Ice Cream Sandwich, Google used TI OMAP as the template for the operating system so many manufacturers have to replace the HAL.
Sony Ericsson, and indeed most OEMs, rely on a fairly consistent hardware design across a range of products. Chips are usually sourced from the same makers, and the internals reuse many smaller parts. Sony Ericsson uses Qualcomm’s Snapdragon processors in phones, so a new HAL is required. At least its consistent design saves some time and will allow the company to update all 2011 phones.
Motorola is currently straddling both Tegra and OMAP-based products, so its task could be more complicated. The newer OMAP devices like the Droid Razr and Bionic could get preferential treatment because of easier development. In fact, Motorola’s OMAP devices are the only products it has confirmed will get Android 4.0. Users of the Photon 4G or Droid X2 could have a longer wait on their hands.
All OEMs also have to contend with small differences in various other hardware modules like audio, WiFi, and Bluetooth. The HAL will need changes on a per-device basis taking into account different form factors, screen sizes, and specs, too.

OEMs tweak and test

The next order of business is a bit more controversial: OEMs start changing Android to suit the needs of carriers and other partners. Patches, custom interfaces, and other miscellaneous changes are made, and the resulting software image is tested. Sony Ericsson went to great pains to point out that many of the internal patches it develops are useful for the Android platform in general, and it contributes those back to the AOSP.
All OEMs have to do extensive internal testing after making changes to the Android platform. A huge concern on a multitude of devices is battery life, and this is the phase to test that. Quite a few of the changes made to localization and features have the potential to turn out buggy and damage power efficiency. The carriers of course want to do network testing, which can occasionally root out still more bugs.
After what is ostensibly the final code has been internally tested, it sometimes has to be certified by regulatory agencies. The device will of course have been certified by regulators in various nations around the world prior to the original release, but sometimes new inspections are required. Any time software changes the function of a wireless chip, for example the Bluetooth stack in Android 4.0, that component needs to be re-certified, adding additional delays. Compliance with hardware standards may also need verification.

The rollout

The act of rolling the update out will vary greatly depending on the device and the carrier branding, if any. Motorola prefers to use a small group of testers to sweep for bugs one more time, then send the update to a group of a few thousand regular users. This is called a “soak test.” The manufacturer probably has dozens of test devices, but there is no way it can test every possible combination of software and settings. More than a few updates have been pulled back after a disastrous soak test. If all goes as planned, the update is released, and everyone can rejoice.
The entire process is a much more tangled web than we would have expected, and remember that OEMs have to do this for every device that gets updated. Sticking to a single hardware platform like Sony Ericsson or HTC has will be of help in getting all devices up to date. Motorola might leave some phones from the first half of 2011 behind for this reason.
Trying to get official word on the fate of one device or another in respect to updates can be nearly impossible, and this is why. The process is long and complicated. OEMs simply don’t want to say the wrong thing, and have to backtrack later. One component that is found to be non-compliant during testing can set things back dramatically.
These new details, especially Sony Ericsson’s forthrightness, help explain why the process takes so long. Hardware differences among different OEMs, and even different devices made by the same OEM, can require unique software builds. Certifying an upgrade takes time as well; apparently longer than actually building the software does. Add to that the lengthy carrier testing phase, and its no surprise that custom ROM makers can get updates out faster. They get to skip the more tedious bits.