I’ve been using Android mobile phones since Eclair (2.1). While the operating system visibly improved at each iteration, updates were, and still are, a major pain 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 readily available, a six month old release. Lots of budget phones sold in 2017 come out with Android 6.0, a version that’s more than 18 months old at the time of writing.
Most devices are sold on carrier contracts. Chances are that updates have to go through several gatekeepers. The first one is Google, then hardware vendors, then phone makers and finally the carrier itself. Each step requires validation, testing, then more validation, and then 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 major updates get hugely delayed 1. More often than not, this also means that devices are not getting quick security updates, which is worse. The latest round of security vulnerabilities means that receiving the wrong SMS/MMS or being near the wrong Wi-Fi or Bluetooth radio could result in a compromised device. People have no control nor defense against this, besides patching security holes.
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 major platform 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.
I don’t think Google will choose the former, since it goes directly against the very reason that made Android popular in the first place, and would risk Google’s relationship with hardware partners (e.g. Samsung) and carriers.
I am more confident that Google will try the latter. We’ll see how this one pans out.
Which is, arguably, a minor loss if you are not interested in features or efficiency gains. ↩
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. ↩