Android Update Release Cycle Explained

In the last few weeks I’ve been exposed to a lot of bad press around the Android release cycle. Much of which is due to journalists who simply have not done their homework with regards to the Android release cycle – misconceptions due to a lack of understanding on how new Android releases are created and delivered to handsets. It’s not an executable file that Google sends out to your phones; in fact Google has very little to do with the update schedule.

Here’s how the Android release cycle works:

• Google internally develop and test an Android release. This release is “pure” Android that does not have any of the customisations, software components (drivers) that marry to the hardware, manufacturer customisations, etc.
• Google will generally progressively test the new release (e.g. to make sure it works) on a real-world phone. This phone generally becomes the base for the next Nexus device for that release.
• After intense testing of the pure version, Google will hold a press release, announcing the features of the upgrade, and generally also announce the Nexus device. This is the stage which begins journalist-release confusion, because what Google are actually doing is demonstrating the new features of the Android OS far ahead of time, as they are soon to release the SDK which contains an emulator image with an implementation of the new features, as well as the source code. At this stage a company such as Apple would still be tight lipped on features, but due to the open source nature of Android this becomes known to the public and thus it is in Google’s best interest to publicise the new features.
• Soon after the press release, Google will release the Android SDK which contains all the relevant tools/classes to develop for the new OS, as well as the emulator image containing new features.
• Following this, Google will then release all of the Android source code. Only at this stage do manufacturers get direct access to the next version of the OS and begin working on the upgrade for their handsets. In the Apple (release) world, the public still has no idea what is in the next version, because iOS is not open source and Apple does not need to provide the source code to any other parties (no one else manufactures iOS devices and public will never get to see it), and they have only a handful of handsets and can just do all their internal building and testing themselves. In the case of Android, because it is Open Source it is in Google’s best interest to hold a press conference to announce the features, because the source code is freely available and the public would find out regardless.
• An example of the stuff the manufacturers then need to create for each of their handsets is listed in the image attached to the article. The top 3 quarters come from Google and the AOSP (Android Open Source Project). The bottom quarter is device-specific and is what the manufacturers spend much of their time “doing”.

• Most manufacturers will concurrently develop their own customisations over the top of the default Android look, feel and functionality (e.g. HTC Sense and TouchWiz, including many of the blue sections at the top of this diagram). Devoting resources to developing these customisations also takes a significant amount of time.
• They then need to rigorously test the device themselves, perform User Acceptance Testing, test again. In the Apple world the public still has no idea what is in the next release, but in the Android world Google announced the release features and dropped the code several months ago. Normally at this stage Google has had a head start with internal testing of their Nexus device from day 1, and this is around the next Nexus device is released.
• Finally, the update is passed on to carriers (phone companies) to test. Here is where the real bureaucracy begins, and where an unnecessary 1-2 month overhead is usually added just to do a bit of network testing (this is something that should really only take 2-3 days if no problems in my opinion..).

So the perceived “lag” for Android updates is really just that – a perception. It’s about when the public is told about the device and it falls down to Android’s open source nature. The alternative is to close the doors, scare everyone away and kill the Android handset developer community – just to receive the updates on the same time schedule.

Notable is that while I fly the Android flag, Apple’s release cycle is definitely tighter. But the finger is generally pointed at Google, and what is not realised is that it is not Google’s responsibility to be building drivers for hardware for every handset released (in fact this is completely infeasible). They aren’t the ones producing the phones so there’s no way they would have the required knowledge on handset, hardware and associated software. IIRC Apple has the carrier testing part fleshed out – they either don’t have to give the testing to the carrier or do minimal testing. The “one handset to rule them all” thing also far simplifies the resources required to roll out new updates, and Android handset manufacturers are slowly starting to get this (Samsung and most recently HTC). If carrier bureaucracy could be chopped through we’d start to see some nice improvements.

This is a community blog post by Reece Wagner. You can contribute too!