Android's Update Problem: 2017 Edition

This is an annual series on the ongoing issue of Android OS updates. Click here to see last year's edition.

In many ways 2017 may be the worst year when it comes to Android OS updates. While Google continues to push more important additions through the Support Library, providing backwards compatibility to previous versions of Android, there still remains so many things that rely on good ol' AOSP. Standing for Android Open Source Project, AOSP is the open source operating system that remains the bedrock of all things Android. When Google advertises a new dessert update every year, it's actually a branding around what is essentially a new AOSP release. Unfortunately for us Android users, AOSP is the piece of Android that is in the hands of chip vendors, manufacturers and carriers to push to your phone, if they do at all.

2017 in particular has been a harsh year for AOSP, with serious security vulnerabilities found, and with it an equally harsh reality check that potentially millions of Android phones may remain vulnerable forever. But 2017 is also a year of hope for Android. A herculean engineering effort from Google has literally changed the way that Android is integrated into the phones of the near-future, and with it comes a hope that the worst aspects of Android updates may finally be behind us. There's a lot to look back on in 2017, so let's get started.

A Look Back on Android's New Beta Process

Starting with Android Nougat, Google decided to release their dessert releases extra early. This meant that developers now had more time to plan their apps for the next SDK release (every OS update comes with a new SDK revision), and manufacturers had more time to tinker with the new release it can be integrated with their OEM-specific features sooner.

It was a pretty exciting time, to be honest. While it meant that Android announcements had less excitement to them during Google's annual keynote since they were announced much earlier, the idea that developers and enthusiasts could get their hands on a new version of Android much earlier (assuming you had a Nexus or Pixel phone) was a far better prospect to get hyped over. I also think that some OEMs have successfully managed to make the best of these earlier alpha releases. In 2016 LG managed to release the V20 with Android Nougat out of the box, and this year we got instant Oreo releases for the Sony Xperia XZ1 and Huawei Mate 10.

It looks like having to wait the following year for a phone shipping with the latest Android version is now firmly a thing of the past. If you happen to own a Pixel phone or one of the latest flagships from Sony or Huawei, 2017 has been a pretty good year overall. For the rest of us, this year has been the complete opposite.

Android's Drivers from Hell

It's been clear for the past few years now why these downstream companies shouldn't have such decisive control over the roll-out of Android updates; serious security issues have been found in parts of Android that currently do not fall under Google's jurisdiction. Last year's elephant was MediaServer, an open source dependency in AOSP responsible for powering all things media such as audio and video. Turns out MediaServer was a cesspool of critical vulnerabilities that have been around since the earliest days of Android. These vulnerabilities, collectively known as StageFright, took an enormous overhaul of MediaServer in Android 7.0 Nougat to stomp out most of them for good.

This year's Android vulnerability story is much worse.

There really isn't one thing responsible for all the bad vulnerabilities of 2017, rather a collection of similar mistakes that allow for device exploitation. This year we had to content with bad drivers.

It turns out it is really difficult to build truly secure drivers for a myriad of reasons. One such reason is that they reside in kernel space, which in layman's terms means that they have almost unfettered access to the device in exchange for remaining fast and efficient. Should these drivers have any programming errors in them that allows malformed input (say a rouge WiFi packet) to break its walled garden, this incoming input could then execute its malicious payload code because residing in kernel space allows them to do so.

Android has suffered severe vulnerabilities this year based on execution of dangerous code coming from bad data packets, namely Bluetooth and WiFi packets. Blueborne was a family of vulnerabilities that affected nearly all Bluetooth devices, taking advantage of flaws in either Bluetooth's design or its implementation to be able to run malicious code. KRACK exploited a WiFi design flaw that allowed attackers to break the WiFi encryption and snoop in on wireless communications. Android was actually the worst victim of KRACK, since a flaw in a Linux library used by Android allowed KRACK to make the device use a key of zero, which is nearly the equivalent of unencrypted communication. There was also Broadpwn, a severe bug found in a specific Broadcom WiFi chip that allowed for remote code execution on affected devices. What makes these vulnerabilities so dangerous is that they require almost zero interaction from the user; no phishing necessary. That means you can be infected just by being at the wrong place, at the wrong time.

Something to keep in mind about all of these vulnerabilities is that they are not exclusive to Android. In fact nearly all of the vulnerabilities I just mentioned affected iOS as well. But there is a distinct advantage in iOS's favor: Apple actively patches these vulnerabilities while the Android ecosystem at large does not. As you read this, hundreds of millions of Android devices remain vulnerable to these deadly attacks because their version of Android is too old, or their manufacturer or chip vendor has deemed these devices obsolete.

It's a terrible situation to be in, as we have to come to grips with manufacturers who stop supporting their phones' software the instant it flies of the shelf, as well as manufacturers who can't update their phones because they can't get the relevant drivers for the latest version of the OS.

Google has known for a while now that the big dessert updates (that by the way also come with important security architecture changes) are too time-consuming and too expensive to carry out sustainably. Even the patches coming from the security bulletin are too much of a hassle for manufacturers that can't or won't spare the resources. Clearly something had to change. Luckily that is precisely what 2017 gave us.

A New Hope: Project Treble

All Android devices that ship with Android 8.0 Oreo must now implement an Android architecture that has been given the codename Project Treble. It is a major modularization effort by the Android Engineering Team that separates AOSP from vendor specific implementations. This is a major shift from how it worked before, where chip vendors like Qualcomm would have to make a Qualcomm-flavored version of the newest Android OS for each of their processors every year. It is both a taxing and inefficient process, and it should come as no surprise that companies like Qualcomm drops support for older chips surprisingly early (R.I.P. Snapdragon 801).

There is plenty of mumbo-jumbo going around that explains how Project Treble works, but the simplest way I could explain it is that Project Treble defines what is essentially a set of hardware standards. Chip vendors and hardware makers can design their hardware however they like, but at the end of the day their final implementation must pass these standards in order to run Android at all. As long as they are met, and future versions of Android are built to use these standards, the Android OS will just work on these chips without any additional effort from the hardware makers.

There are still some caveats to be mindful of, though. OEMs are still free to tweak AOSP to their liking before pushing an update to its users, so we're still not at iOS levels of speed here, mind you. There is also the fact that Treble's hardware standards will have future revisions as well (think v1.1, v1.2, v2.0) to support future hardware features such as Bluetooth 6 or gigabit WiFi. Hardware makers will have to update their hardware code to support these newer standards, though its not clear how pressured they will be to do so for their current chips or even for future hardware. The good news is that future versions of Android can be backwards compatible with older hardware standards, so it's not instant death for a specific piece of hardware just because it doesn't support the newest standard. Still, old hardware standards will eventually have their support dropped, but how long that will take remains up in the air.

Another cool thing brought about by Project Treble's modularization is that drivers can now be updated separately from AOSP. Starting with Android Oreo, graphics drivers can be updated through the Google Play Store, meaning performance and security patches for the GPU can bypass the OEMs and carriers and be installed on the user's phone as though it was just an app, because it is! Considering that we may not have heard the last of Bluetooth and WiFi vulnerabilities, I hope that future work on Treble will allow wireless drivers to be updated over the Play Store as well.

Looking to a (Hopefully) Brighter 2018

So yes, 2017 was an absolute mess for Android, but I also want to be optimistic as we start rolling into 2018. Make no mistake that project Treble is a game-changer for Android updates. Even if you end up with a phone from a lazy manufacturer that never wants to update your phone at all, Treble already opens some big doors for those willing to go the custom ROM route, assuming the bootloader is unlocked, obviously. There is also some promise from the fact that GPU drivers can be updated on the phone as an APK. While we can't truly prevent vulnerabilities like Blueborne or Broadpwn, the least we can do is fix them as quickly as possible, and the Play Store is as frictionless as they come. Hopefully the GPU drivers are only the beginning of a better security story for Android.

The last real bottlenecks left going into 2018 are the OEMs and the carriers. While I suspect that Touchwiz is still going to stall a lot of updates for Samsung devices in the near future, hints of a theming engine in Android Oreo gives me hope that Google is tackling the manufacturer bottleneck head-on as well.

As for me, I'm kinda excited about what my next Android phone could be. I've been rocking iPhone since my last Android phone, the Sony Xperia Z3 Compact, was inflicted with touch disease. While the iPhone is wonderful (and also more secure), I do still want to keep an Android device around for the unique things it can do. I may hold off on getting a new Android device until Project Treble is more widespread on low-end and mid-level devices. That way I can get a phone that lasts way longer than even the manufacturer's own intentions, thanks to the custom ROM community.

By all accounts 2018 should be a better year than the one we're about to leave behind. Let's hope nobody botches it.