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

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.

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

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.

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.

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

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

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.