To solve Android’s update woes, Google should look to the PC

Op-ed: Android's update model should be more like Windows, less like iOS.

Enlarge / You know, there was some other huge platform that handled the update problem much more gracefully than Android. What was it called, again?

Andrew Cunningham

Android updates have gotten a little faster over the last two years, at least if you invest in a flagship smartphone from a major company. We have reams of data that say so, and we can even tell you which carriers and companies you should stick to if getting updates factors heavily into your buying decisions.

Further Reading

Naming and shaming (sometimes praising) the update efforts of OEMs and carriers.

But wouldn't it be great if you never had to think about this stuff at all? If you never had to read another multi-thousand word story about Android update speed, because it wasn't a problem anymore? We spend so much time discussing the state of Android’s fractured landscape and watching it improve baby step by baby step, but there has to be another way forward.

In fact, there's already a shining example that Google could decide to imitate. These devices come from many different manufacturers and use all kinds of different CPUs, GPUs, screens, and other components. There are hundreds of millions of them sold every year, and their operating system can be customized with additional apps and services to help differentiate them from one another. And yet, despite this fractured landscape, the operating system that runs on these devices gets security and feature updates on the day that they're released. Read any article about Android's update problems, and this sounds like a fairy tale you'd be insane to hope for.

That platform is the lowly, boring Windows PC, and Android could really stand to take a page or two out of its book.

Ease ARM’s platform pains

Further Reading

Microsoft is talking in detail about Windows 8 on ARM, or "WOA" as the company …

The x86 PC is a platform. Chips not only share the same instruction set, but they connect to standard controllers and peripherals using standard buses and interfaces. Operating systems know how to interact with all this stuff. Some of those peripherals will need drivers to enable all of their functionality, but if a new kind of CPU or motherboard comes out, you can grab any recent Windows or Linux install media and get your system working without having to think much about it.

To oversimplify a complex issue, ARM hasn't worked the same way. Different SoCs use the same instruction sets, but vendors handle other things in ways that are often unique to each SoC, and for a long time those differences required custom Linux operating system kernels just to get things working. Linux kernel creator Linus Torvalds put it best (and the most colorfully): “this whole ARM thing is a fucking pain in the ass.” There’s another good article on the problem at LWN.net.

These improvements haven't made it to Android yet, though—Linux kernel 3.7 was the first to unify ARM support, and Android 4.4 (and the L release preview, for that matter) uses kernel version 3.4. Google hasn't offered its own, alternative version of an ARM "platform." This leaves OEMs and SoC makers to do most of the work of getting Android running on different hardware rather than freeing them up to focus on user-facing features (here's a quick DIY crash-course made for people trying to run Android on ARM developer boards, just for reference). Google provides kernels that can serve as “starting points” for various ARM chipsets, but they aren’t finished products.

According to the market share numbers, Android is the biggest ARM platform in the world, and yet it doesn't offer hardware makers the same wide, generic hardware compatibility that Windows and Linux (and even, with some work and many caveats, OS X) enjoy on PCs. Google could certainly fix that.

Kill the monolithic OS update once and for all

Further Reading

Android originally followed the iOS model for software updates. iOS updates give you high-level, user-facing features, new developer APIs, new drivers for graphics and other hardware, and modem firmware all at once in big updates like iOS 7.0 or 7.1. Apple can make this model work because it has full control over most of these different software layers, because it has just a few different devices to support, and because those devices share many common components (cellular and Wi-Fi adapters, GPUs, and so on).

Android was originally built to be updated in the same way, with user-facing features and low-level changes all delivered in big, monolithic updates. Given Android's decentralized model, though, a delay in any part of the update—your baseband firmware and the associated carrier validation, your OEM skin, your built-in apps—can delay the entire update. Android spread so quickly and so widely and it ran on so many different types of hardware that this style of update quickly became untenable.

By the time Gingerbread and Ice Cream Sandwich and their extensive app updates and UI changes rolled around, it was clear that the monolithic approach wasn’t going to work. While things have gotten better, it's still holding Android as a platform back. Consider that, as of this writing, less than a third of Android devices can connect to the shiny new smartwatches Google and its partners are pushing because those devices don't run Android 4.3 or 4.4.

This is how long you have to wait for a monolithic update to come together if you're an Android user.

For reference, this is how long you have to wait if you're an iOS user.

We’ve already written about the alternate approach Google is now pursuing: many feature updates have been broken out into separate apps. Any Google-approved device that meets the minimum software requirements (usually Android 4.0 or 4.1, depending on whether they require Google Now) can grab updates for apps like Chrome and Gmail without having to wait for their OEM or their SoC manufacturer to catch up. Google Play Services can enable some new features and APIs and provide some security patches without requiring a whole new version of Android, too. Even more important pieces of the OS like the keyboard and the app launcher can now be downloaded and updated from Google Play.

That's a good start, but let's take it further. Many core pieces of Android—the notification center and quick settings menu, the application switcher, the Settings screen's aesthetics and available options—are still changed via Android version updates and can't be changed, customized, or updated via application downloads. Google's first item of business should be to break these chunks of Android out into the Google Play store, too, while providing hooks for OEMs and third-parties to design their own versions. As we noted, companies are already beginning to update some of their own launchers and apps through Google Play—why not let them do the same with other parts of the UI? This way OEMs get their skins and "differentiation," and users get more choice and flexibility.

The same could be said of the API layer, some parts of which are already updated via Google Play Services. Once you're that deep, you can add many of the features that people associate with big Android updates—things like the new hooks for camera apps coming with Android L or the beefed up SD card security features from KitKat. The biggest question would be about what could be changed and added without breaking existing apps. Supporting new versions of the OpenGL ES graphics API, for example, usually requires driver updates from SoC vendors, which might still need to be included in a larger system update.

Other companies are already making this work

Further Reading

Review: Not perfect, but 8.1 is an OS that actually works for desktop, mobile.

Look at Windows Phone for an example of how we think Google could handle Android. Under normal circumstances, OEMs and carriers do some work on the core OS to add their own apps, validate baseband firmware versions, and so on. But users can bypass those delays by signing up for Microsoft’s (free) developer program, enabling them to grab big, important, feature-packed updates like Windows Phone 8.1 without having to wait. Your OEM and carrier can then release the "final" version of the software with all of the added customizations, baseband firmware validation, and other low-level features when it's done.

In other words, like it already does on Windows PCs, Microsoft can issue Windows Phone feature and security updates without going through the ridiculous multi-step rigamarole that every SoC vendor and OEM needs to do for every Android update to every handset they support. Together with rapid updates for individual Windows Phone apps, Microsoft can keep handsets feeling new for as long as the hardware meets the operating system's requirements, regardless of whether or not the OEM has abandoned it.

As Android matures, it may eventually be possible for Google to implement something similar. Between the Google Play-supplied updates and rumors about clashes with customization-happy OEMs, it's clear that Google wants to regain control over its mobile operating system's trajectory. The company is already exerting more control over offshoots of Android like Wear, TV, and Auto. The logical end game here is a phone-and-tablet version of Android that can be updated by Google with little to no involvement from OEMs and carriers, the same model that good old Windows PCs (and, to a lesser extent, Windows phones) have used for years.

It would be easier for OEMs. It would be better for users. And we could finally stop reading and writing about Android's update problem.

Promoted Comments

Windows RT and more recent Linux kernels have largely fixed this issue, adding enough abstraction between the operating system and the hardware that the OSes can run a wide range of ARM SoCs. ARM (the company) is also aware of the problem and has attempted to define a unified ARM platform specifically for use in server rooms.

This is a good start, but its not a solution in the near-term. Having unified platform support in linux for ARM is great, but you still have to support the rest of the SOC, and that means getting dozens of vendors to port huge amounts of hardware. Maybe someday (Android P or maybe T?), but not today.

Quote:

Many core pieces of Android—the notification center and quick settings menu, the application switcher, the Settings screen's aesthetics and available options—are still changed via Android version updates and can't be changed, customized, or updated via application downloads. Google's first item of business should be to break these chunks of Android out into the Google Play store, too, while providing hooks for OEMs and third-parties to design their own versions. As we noted, companies are already beginning to update some of their own launchers and apps through Google Play—why not let them do the same with other parts of the UI? This way OEMs get their skins and "differentiation," and users get more choice and flexibility.

This is really the key. Google's idea of "firmware" includes things like "a web browser". A web browser is not firmware. Its an application. There is no reason to flash a ROM to change icons around in a webkit view. They have done a lot to sort out their update process, but they're still disorganized.

Ideally, firmware updates should be more like BIOS updates: performed rarely, and only to address critical security or compatibility issues with the underlying hardware, kernel, etc. Everything else, the things that do not touch the hardware directly (which is almost everything on a modern linux system) should not need a firmware update.

Andrew Cunningham / Andrew has a B.A. in Classics from Kenyon College and has over five years of experience in IT. His work has appeared on Charge Shot!!! and AnandTech, and he records a weekly book podcast called Overdue.