Android, Treble and the Updates Situation

4 minute read

I’ve been using Android mobile phones since Eclair (2.1). While the operating system visibly improved with each iteration, updates were, and still are, a major sticking point.

Most non-Nexus and non-Pixel phones don’t get prompt security fixes for the increasingly long security bulletins that Google publishes every month.

Users are also missing out on performance and battery improvements that appear in new Android releases. Most flagship phones released in 2017 had Android 7.1 at a time when 7.1.2 was available, a six month old release. Lots of budget phones sold in 2017 come out with Android 6.0, a release that’s more than 18 months old.

Most devices are sold on carrier contracts. Chances are that updates (if you are going to get them at all, that is) have to go through several gatekeepers. The first one is Google (of course), then hardware vendors, then phone makers and finally the carrier itself. Each step requires validation, testing, then more validation and more testing.

There’s simply no economic incentive for anyone in this chain (except for Google) to support a phone after it has been sold. This means that users get hugely delayed Android major updates 1. More often than not, however, this translates also in not getting prompt security updates, which is worse. Visiting the wrong website or receiving the wrong SMS/MMS, something users have no control over, could result in a compromised device.

In this race to the bottom some manufacturers clearly state that it costs too much to push security updates on a monthly basis. They prefer to roll them up with significant updates, but this means that they are leaving their users unprotected for long stretches of time. Quoting an article from Ars Technica:

Motorola understands that keeping phones up to date with Android security patches is important to our customers. We strive to push security patches as quickly as possible. However, because of the amount of testing and approvals that are necessary to deploy them, it’s difficult to do this on a monthly basis for all our devices. It is often most efficient for us to bundle security updates in a scheduled Maintenance Release (MR) or OS upgrade.

The problem, however, is: how do you sell security to users? How do you get them to vote with their money, the only weapon they have to force vendors to change their attitude? Most people don’t want to spend 800€ on an iPhone 2, which is probably the most secure consumer mobile phone available today. The layperson doesn’t really have a concept of “software updates” and “security”. Even fellow software engineers don’t seem to grasp or fully appreciate the concept! Most people just want a cheap smartphone to use SnapChat and WhatsApp, they probably won’t demand security unless they get hacked en-masse and experience direct economic damage from hacking attempts.

Which means that the burden of keeping users secure lies entirely on Google’s shoulders.

Google recently announced Project Treble, an initiative to decouple generic parts of the Android operating system from vendor-supplied support code by, essentially, creating an HAL.

With this change, vendors will only need to customize the hardware support layer, assuming the HAL is well defined and well separated from the rest of the system. This is a nice improvement since, before Treble, hardware customization usually needed changes spread across the entire operating system.

However, I’m not confident that this will solve anything at all. With this model, SoC and phone manufacturers are still responsible for shipping updates and, as we said before, there’s just no economic incentive for them to update phones. These companies live on razor-thin margins and any cent saved can be spent surviving in this highly-competitive market.

Even on the high-end (i.e. phones that cost more than 600€) things aren’t that rosier. While manufacturers may have an easier time updating the low level guts of the operating system let’s not forget that most players in this space still rely on heavily skinned Android versions such as TouchWiz, Sense, EMUI, etc. Skins slow down updates as much as adding hardware support and Google doesn’t have an answer to make that easier, yet.

I strongly believe that the situation won’t improve at all until Google either:

  • Starts updating the operating system by itself, bypassing manufacturers and carriers, and letting them only manage hardware integration and the baseband processor.
  • Starts exerting more control over partners (especially phone manufacturers) using access to Google Play Services as leverage against vendors who don’t, for example, promise to push monthly security updates to users for at least three years since a phone’s release date. Those failing to do so, should see access to the Play Store and proprietary Google apps revoked.

While the former won’t happen anytime soon since it goes against the very reason Android is successful today 3, I am more confident that Google will try to pursue the latter over the next few years.

Meanwhile, you’ll have to enjoy this messy ecosystem.

Footnotes

  1. Which is, arguably, a minor loss if you are not interested in features or efficiency gains. 

  2. Since Google killed Nexus phones (which were affordable at around 250-300€ for a base model), the only alternative is a Pixel, which often costs more than an iPhone and is supported for only three years. Apple devices are usually supported for at least five years. By choosing a Pixel you are getting less value than an iPhone. By choosing anything else you are getting even less. 

  3. Google let everyone and their dog take Android, run with it and ruin it, in order to gain market share. A big win for Google, a huge loss for users. 

Tags:

Updated: