Android's Update Problem: 2018 Edition

This is an annual blog post I write about the state of Android updates. Click here for last year's edition

I'm happy to say that 2018 has mostly been upside for the state of Android updates. The Android Team promised that under-the-hood changes in the OS's foundations would lead to better update cadence, and after I/O 2018 I'm definitely inclined to believe them. The venerable Support Library, which allows for features with backward-compatible APIs, has also seen a big revamp, so that's also something worth talking about. Lastly, Google is taking a stance on older versions of Android, with the reluctant(?) assistance of its app developers.

Project Treble Bears Fruit

Last year, Google announced Project Treble, a massive engineering effort that provided Android with a standardized hardware communication layer. This essentially allowed any hardware implementations that adhered to these standards to be able to run a new release with almost no modifications. It's not a panacea by any means, since Treble can define new standards that future Android releases will require, leaving outdated Treble implementations behind. Regardless, the engineering required to make existing hardware work with newer releases has been immensely reduced.

In addition, any Android phone that shipped with Oreo were required to implement the Treble standard, meaning all of these phones had the potential to run Android 9.0 and above with little to no additional effort. We saw the fruits of this labor in action at I/O 2018, when the pre-release version of Android 9.0 was immediately testable not just on Pixel devices, but also from phones seven different manufacturers.

It's honestly breathtaking to see phones from disparate OEMs suddenly able to run a brand new Android release, but the seemingly impossible was made possible thanks to Project Treble. It's important to keep in mind that Project Treble only really fixes the chip-support issue when it comes to compatibility. This doesn't mean that OEMs will suddenly have OS updates on Day 1, since OEM customization is still a thing on Android. Even if you were willing to go rogue and install a Treble-compatible custom ROM for your phone, you're still at the mercy of manufacturers providing unlocked bootloaders before you can take the situation into your own hands.

But let's not end on a negative note. Project Treble is fantastic, and my hope is that even more phones will be able to test and run Android Q in 2019.

Introducing Android Jetpack

Google has always provided the Support Library so that some features of newer Android releases were also made available to older OSes through the use of a dedicated library. In 2018, we got introduced to Android Jetpack. The change isn't earth-shattering by any means, but it does allow the Support Library to be something more than just a backwards-compatible API.

Jetpack is essentially the Support Library cleaned up, and for good measure it also adds additional components to help make it easier to build Android apps. It contains APIs that allow for cleaner, more resilient code, and even provides convenience APIs that allow for better-flowing applications.

We're starting to see a more distinct separation between the actual components of Android and the libraries that make it easy to interact with these components. While Android Pie may add new components like Slices, the arguably best way to interact with these components will be through Jetpack. Fortunately, Jetpack can be upgraded more frequently than the OS and even the older Support Library, so developers will always have access to APIs that improve the development experience even on older OSes.

Raising the Floor

App support plays a big part when it comes to the support window of a specific Android version, and Google plans on tackling this issue on two fronts.

Newer SDKs that accompany every OS release often come with new security measures built-in, something that any app can take advantage of by setting its target SDK level. While the minimum SDK level determines the oldest OS that the app can run on, the target SDK level determines newest set of features the app can take advantage of if it happens to be running on that version of Android.

Sometimes, apps will purposefully not target a recent SDK release in order to opt-out of these security measures, which is problematic as Android tries to add additional privacy features to better protect users from malware.

At the end of 2017, the Android team have provided a new mandate that states that apps must target newer SDK releases for their apps, in order to stop them from getting away with features that compromise security and battery life. This is a win for users on reasonably updated phones, since any security and privacy features on your phone will very likely apply to any app you install from the Play Store.

Google is also targeting the minimum SDK issue. While the oldest versions of Android continue to fade from existence, there are some apps that still need to support these OSes. This means Google needs to write additional code so that Google Play Services and Jetpack are able to work on these older phones at all. Eventually, however, these releases will be just too darn old to support any new features, so Google eventually has to say goodbye to these older releases.

Over the last couple of years, Google dropped support for Gingerbread and Honeycomb from Google Play Services and the Support Library. Soon, Ice Cream Sandwich will join the graveyard. This means that an app can only support Android Jelly Bean as a baseline if it wants to remain a modern Android app with access to the latest Google APIs and features. If you're developing an app that is completely severed from Google Services, it looks like Jetpack is still supported for now, however I expect this to change in the near-future, since ICS's market share is getting really close to zero.

Looking Forward to an Upward Trajectory

2018 has overall been a pretty good year for Android updates. Project Treble essentially removes a large burden from silicon manufacturers, meaning OEMs and carriers remain the low hanging fruit. My hope is that further modularization of the operating system will allow OEMs and carriers to not require deep changes to the OS in order to get their customizations out the door. I personally would prefer that no customizations be allowed at all, but there's no way we can enforce this ideal in a world where Samsung is king.

On the security side, I'd still prefer if more drivers be allowed to use the APK method of updating, but hopefully Project Treble's modularity can at least ease the pains in this space. Apple's model of security updates remains the gold standard, and I hope Google at least uses iOS as a compass towards day one security patches for all parts of the phone.

Given the enormous strives that Android updates made in 2018, I'm going to have higher expectations for next year. While Android Pie did bring cool features such as Slices and Digital Wellbeing, I suspect that more of the features that impact developers and users will be coming through the always updatable Jetpack library. Even if some of the best features of Android Q will require a full OS upgrade, my hope is that Project Treble and further efforts from Google will set a better norm than we had in the last decade of Android's existence.