Why the Long Delay on Android Updates?

This is actually a modified + translated version of this piece I wrote in danish: Opdatering Android (PDF).

Google develops the operating system Android. The speed of the development is as fast as the whole smartphone business – and that is fast – which means that a lot of stuff is happening all the time. Android gets support for new functions and technologies like NFC, bigger screens, e.g. Many of these updates are about hardware support – both support of new hardware and improvement on currently supported hardware – and a lot of updates purely focus on the software that millions use every day. These are improvements of stability and overall use experience. When Google announces these updates, most users (those who hear about them) feel a natural need to get these as fast as possible. Often, it will take quite some time though – from the time updates are announced by Google – until it can be downloaded and installed on the phone of a user. Why is that?!

In addition to that question – Apple is constantly announcing updates to their iOS platform that is ready to download on all units worldwide right away – or within very little time. If Apple can do this, surely Google could to! I will try and describe why this update process is actually harder for Google – and why Apple doesn’t face the same problems.

Google develops Android with a specific reference platform. They have a piece of hardware (phone or tablet) which they develop a specific new version of Android for. The new version is tested to match the capabilities and stability of the hardware and software. The specific hardware implementation decides which features new versions of Android will support. Usually, Android versions are built for the Nexus-line of phones which contains hardware features that Google wishes to include. By developing this way, Google is creating a software platform they can license to their partners and even Open Source.

When a hardware vendor (phones) develops a smartphone, it will need an operating system. For every vendor other than Apple, this is a choice between Android, Windows Mobile, Symbian, MeeGo, etc. – if Android is chosen, it means that the vendor uses the software platform provided and adjusts it to fit the specific hardware implementation that is their new phone. This process involves writing driver implementation for hardware, etc. and adding this to the Android platform. To be different on a market of so many Android phones, many vendors choose to add another layer of software to the standard Android experience. Examples of this are the HTC “Sense”-UI. Customizations like this will also need to be adapted to specific hardware (phones) – which is usually a lot smaller task than customizing Android because it expands and extends software at a much higher abstraction level.

This means that when Google is ready with a brand new version of Android, the hardware vendors need to determine if their hardware can actually run the new version including their own custom changes. This is usually a trial-and-error process which naturally means that it will take some time. Sometimes, the network operators even have customizations and pre-installed applications which just adds another layer of development and testing and further delays the process. All this customizations must be completed before the phone vendor can start rolling out software updates. Older hardware has limitations and might not get certain upgrades that are basically incompatible. Furthermore, the hardware vendors make money selling hardware – not directly by supplying software updates – which leaves the simple question: Do they even want to do it?

The situation that Apple is in is a lot better in regards to software updates. They develop software (iOS) exclusively for hardware that they also produce. This means that the software developers making the new iOS version can actually test it on every single specific hardware unit that the software is ever going to run on. That effectively removes a layer of software development and testing compared to the Android model. Adding to that – Apple made the clear decision very early on that they will not support network operator customization. Yet another develop/test layer possibly removed. When the updates are distributed, it comes directly from Apple's servers into the iOS units (or though iTunes) – compared to Android which could be distributed from the hardware vendor servers or even from the network operator.

It is hard to imagine how this situation could be improved in the future – it will most likely require that Google put some kind of pressure on the hardware vendors. This is a possibility but it seems very unlikely considering that this would also up the requirements of backwards compatibility and future hardware demands of the Android platform – which will definitively slow down the development of new and much better hardware or even cause further fragmentation of the platform.