The next Android version’s killer feature? Security patches

Big news for Android users – the next version of Google’s mobile OS will require device makers to agree to implement regular security patches for the first time in the operating system’s history.

For now, the only evidence we have for this development is a brief and easy-to-miss comment made at last week’s I/O conference by Android’s director of security, David Kleidermacher.

Still, his words don’t leave much wiggle room:

We’ve also worked on building security patching into our OEM agreements. Now this will really lead to a massive increase in the number of devices and users receiving regular security patches.

About time security watchers will say as they survey the mess of Android’s fragmentation, which, paradoxically, has grown more pronounced as the OS has recently matured.

That maturity has come at a price – a new version every year – which sounds great until you contemplate the consequences of large numbers of devices with security vulnerabilities that won’t or can’t be patched.

Android fragmentation happens on two axes at the same time, namely the annual updates to the OS (which add new features and architecture tweaks), and monthly security updates.

Consider that in the nine years between Android Cupcake in April 2009 and the forthcoming Android P, Google will have produced 14 versions of its mobile OS.

Granted, only a few of these will be still be active in many countries but even chopping out older incarnations would leave us with:

  • Version 5 (Lollipop) – November 2014
  • Version 6 (Marshmallow) – October 2015
  • Version 7 (Nougat) – August 2016
  • Version 8 (Oreo) – August 2017
  • Version 9 (Android P) – August 2018

Not forgetting all the point versions for each that sit in between these annual revisions. Even those running the latest version on a new phone face a problem of getting regular (or any) security updates – currently, only Google-branded devices receive monthly security fixes, which the company documents on its developer’s site.

One important reason for delayed or non-existent updates is that each hardware vendor had to heavily customise Android to work with their devices.

Google’s answer from version 7 onwards was Project Treble, an updating architecture that separated the Android OS from hardware-specific code.

This has improved the frequency of patches for other vendors, but it’s still a long way from perfect with many Android devices months behind at best.

Kleidermacher’s comments indicate this is about to change. We still don’t know what “regular” will mean in practice but it’s hard to believe Google wouldn’t impose the same monthly cycle it works to for its own products.

This heralds a big culture change for Google’s relationship with device makers, which has traditionally been arm’s length by design.

The wrinkle for Google is that even smartphones that appear to have been patched, often haven’t, with researchers recently uncovering a wide variety of missing patches on devices that have officially been updated.

It’s a third and largely ignored level of fragmentation that underlines how difficult the issue has become for Google.