How a yearly release cycle could improve the Android experience

Back in 2010, when Andy Rubin was still heading up Android, he told Mercury News, “Our product cycle is now, basically twice a year, and it will probably end up being once a year when things start settling down, because a platform that’s moving — it’s hard for developers to keep up. I want developers to basically leverage the innovation. I don’t want developers to have to predict the innovation.”

If you look at the Android version history, you can hardly fail to notice how erratic the release schedule has been. In the early days of the platform, it was important to rush, because Android was playing catch up, and there was a lot to do. Each new version brought a raft of essential features, but that’s no longer the case.

There are now signs that Google might finally be settling into an annual update schedule, albeit later than expected. Android 5.0 Lollipop landed a year after 4.4 KitKat. Google announced it in June at Google I/O 2014, providing time for a developer preview before the consumer launch in November.

Smaller updates with bug fixes are inevitably going to be released throughout the year, but it looks as though Android M will follow the same pattern.

A lot of benefits

You would assume that having a concrete schedule in mind would be a good thing for the Android team at Google. It’s not a rush to push out new features with the decision on when to ship being made as they go. It should improve the chances of a stable release that’s been properly planned and tested, at least in theory. Nexus owners can attest to the potential impact of bugs in new Android versions.

Predictability and stability are big potential pros for developers and OEMs. If they know when a new version is set to land, then they can plan accordingly. Having to guess isn’t ideal, and it can obviously be pretty frustrating. For OEMs it would provide a nice foundation for their own annual flagship releases. Some manufacturers have stuck to big shows, like MWC, others have chopped and changed every year, but a fixed schedule makes it easier to build hype and expectations.

It should also make it easier for developers and OEMs to plan updates. Previews help developers to ensure that their apps and games work with the latest Android version on day one. Manufacturers can theoretically make the necessary tweaks to their UIs, and push new versions over-the-air (OTA) within a predictable timescale. The current situation is a rush. Often by the time the update actually goes out, Google is announcing a new version of Android.

For consumers, a predictable release schedule for new Android versions would be great. As it stands, the fragmentation situation is very frustrating for device owners keen to get their hands on the latest and greatest features. When Google decides to update Android, there’s a wait to see which manufacturers will push it to their devices, and then another wait for the carriers to make their changes before the update can be pushed out OTA. HTCreleased an interesting infographic about the update process a while back. You can see how a stable timetable and longer gaps between releases might help. Fragmentation isn’t going to be solved by the annual cycle, but it should certainly make things a bit more transparent.

A yearly cycle also means one big exciting release with a new feature list, instead of a stream of smaller updates. It brings a bit more clarity to the divide between versions, and it makes it harder for OEMs and carriers to justify not updating. With fewer updates to deal with, perhaps they’ll start to update devices for longer.

And a few drawbacks

The reason that Google hasn’t had a yearly cycle thus far, is to do with the pace of innovation. More frequent releases provide the opportunity to push out new features and cool functionality as it’s developed. With a yearly cycle we’re going to have to wait a bit longer to get the new goodies.

OEMs feed off each other right now, with the competition pushing them to innovate, and a steady stream of new devices hitting the market year-round. A single annual update model could deflate this constant jockeying for position, and slow innovation further.

Security is an issue. If there’s one improvement you don’t want to wait for, it’s the closing of a vulnerability. Bugs are never intended to be part of a release, but unless Google ups its game in terms of defects in new versions of Android, the wait for a fix could grow longer. Even with a yearly cycle, small updates for security and bugs will surely be inevitable.

Is it the right move?

There’s another compelling reason for Google to switch to the annual cycle that we haven’t mentioned yet. The move to deliver new features within Google apps is clearly underway. We don’t always need a platform update to get more out of Android. Regardless of how you feel about this trend and Google’s motivations for it, there’s little doubt that it’s happening.

It’s also worth remembering that Google is starting to push Android for Work and it wants the platform to challenge for the enterprise. Businesses, IT departments, and enterprise app developers want stability, and expect a stable update schedule. For planning purposes it may be seen as a prerequisite that’s currently harming Android’s credibility.

The Android platform is mature. There’s always room to innovate and improve, but we aren’t seeing vital new features in every update. As Google moves towards the refinement process, it seems to make sense to slow down and reduce the disruption of a faster release cycle. It may be difficult to determine whether it will have any impact on the pace of innovation, when it feels as though innovation is already slowing, but the potential benefits for developers and OEMs will hopefully be felt by end users as well.