Android's Update Problem: 2016 Edition

Android 7.0 Nougat is finally upon us! It comes with awesome new features such as split-screen apps, native VR support and better power management. On the backend side of things Nougat also introduces some much needed bug fixes to prevent future security exploits like Stagefright. It's looking to be a pretty nifty update, but what's also upon us is yet another year where we have to contend with the recurring elephant in the room that is Android's OS update problem.

Every yearly Android update comes as bittersweet for several million mobile users. Unlike the reliably updated iOS, Android updates start out as complex situations and only get worse from there. This conundrum has been a notable part of Android's story since its rise to prominence, and despite herculean efforts by Google there appears to be no end in sight either.

Expect future editions of this series in the coming years.

Google Bypasses the Monolithic Updates

It was in Google's best interest to keep Android up-to-speed in order to ensure the best Android experience possible. A less fragmented install base meant easier (and cheaper) maintenance, and happy users meant a reliable number of users to sell ads to. The problem is the business model of an OEM or a carrier is intrinsically at odds with software updates (especially free ones). That means the old way bringing in new features through monolithic, OTA updates wasn't going to cut it.

Google essentially came up with two big solutions that still positively affect the Android ecosystem today. The first solution was Google Play Services, an Android superapp that was installed on every Android phone made since 2010 and contained all the latest Google APIs. Since Play Services updates itself through the Play Store (this is how it adds new Google APIs) without having to wait on OEMs or carriers, even 3rd-party apps running on old versions of Android have access to the latest Google features. A prime example of Google Play Services at work is when Google introduced Nearby, a new set of proximity-aware APIs.

The second solution Google came up with was the Android Support Library. Google's idea for how an Android app should look and behave is constantly changing, and the Support Library was its way of allowing developers to implement new Android app design on older phones. Instead of making apps rely on features included with a specific Android version, these apps can now ask the Support Library for those same features, and the Library itself will take care of implementing those features over multiple versions of Android.

The result of both of these Google solutions is that even phones running a version of Android made in 2011 can run an app that was built, designed and released in 2016.

Are Android Updates Still Important?

Despite Google's efforts to decouple vital parts of the Android experience from the monolithic updates of the old world, some things can really only be updated through the operating system. Things like support for new Bluetooth standards, updated core Android behavior (like multi-window apps), and security updates to the Linux kernel will remain things that OEMs and carriers can neglect to push to customers. Even the Android Support Library has its limits, as parts of the new Android app experience such as smooth transitions and new camera APIs remain locked behind newer versions of Android. As cool as it is backport Material Design to phones running Android Gingerbread, it's nowhere near as easy for Google, developers and users if that phone could just upgrade to Android Nougat.

While you can argue that having support for the latest version of Bluetooth isn't very important, security continues to be a thorn in Android's side. There are many vulnerabilities that Google Play Services isn't allowed to patch on its own, Stagefright being the most notable one. While Google Play Services and the Google Play Store are excellent in preventing malware from being installed on users' phones, there are still many ways to hack into an Android phone.

Attacks like Stagefright use specially crafted audio and video files to perform a hostile takeover of one's phone, and there's no shortage of media on the open web. The worst examples of these kinds of attacks don't even need the user to do anything; merely being sent a text with a malformed video is all it takes to activate some exploits.

Google has done its best to make security patches more accessible, even if they have to go through the monolithic update process. There are now much smaller Android updates available to OEMs that focus on security patches and hopefully only need minor testing before being sent to users. Nevertheless trust issues with OEMs still remain.

Google is also taking some longer term solutions. Problems like Stagefright largely stem from a specific Android module called mediaserver, and it's been responsible for handling video and audio for Android since the beginning. Google decided that it needed to rewrite mediaserver if it wanted close-off malformed media as an attack vector for good. That's why a new and improved mediaserver shipped with the Android Nougat update. There's just one issue...

The Great Android Divide of 2016

The problem is that a large amount of Android phones, many of them flagships, will never see Nougat arrive, not officially at least. While the details remain the realm of speculation, word on the street is that Qualcomm will not provide Nougat drivers for the Snapdragon 800 and 801 chips. It sounds harmless at first blush until you realize that these chips power a non-trivial number of flagships that really aren't that old. These flagship phones include the Google Nexus 5, the Samsung Galaxy Note 3, the Samsung Galaxy S5, the HTC One M8, the LG G3, the Sony Xperia Z1, Z2, Z3 and the Oneplus One. These are all still perfectly usable, performant phones, but a business decision upstream means that these phones may remain vulnerable to exploits that may still reside in legacy code.

The problem with Android updates is that all involved parties (and there are a lot of them) need to put their stamp of approval before it ever reaches your phone. What's so damning about this year is that for all of these flagship phones I just mentioned, the Nougat update didn't even get past the first hurdle (the chipmaker a.k.a. Qualcomm).

Oh, and there's still the fact that an even larger number of users using equally old non-flagship Android phones have been left out by extension as well.

Where Do We Go From Here?

A part of me wants to say that we shouldn't feel too bad about not getting Nougat (I personally own a Sony Xperia Z3 Compact), but the spectre of Stagefright (and all its sinister sibling exploits) looms too large for me to ignore. Android is a platform with many layers, and while Google has firm control over the top layers, too many parties with little skin in the game have too much control over the lower ones.

It's hard to tell if Google will be able to expand Google Play Service's powers to cover more parts of Android like mediaserver or the Linux kernel, but I wouldn't hold my breath on that.

As for the Snapdragon 800/801 conundrum, while it's painful to see these chips dropped so soon, it's probably because they didn't support newer features and APIs[1], the kind that modern chips thankfully already support. My hope is that we won't see another sharp divide like this in a long time.

If you are an owner of an unsupported phone like the ones mentioned earlier and are concerned with currently existing vulnerabilities, it may be time to exercise your right as an Android user and look into custom ROM options. Hopefully your phone manufacturer is amenable to unlocking your phone's bootloader so that this option is even possible in the first place. If not, hopefully the security problems plaguing Android right now will make them realize that unlocking abandoned Android phones is a moral obligation.


  1. I'm specifically referring to the Vulkan graphics API and native support for encryption. The Snapdragon 800 and 801 are possibly being left behind because they support neither of these. ↩︎