Google started releasing monthly security updates for Android back in August 2015. Modern Android devices show you the latest monthly patch level that has been applied. The responsibility for deploying the patches ultimately falls on original equipment manufacturers (OEMs) and carriers, who need to test the security updates on their devices to ensure that they do not break any functionality. Google does provide updates for its Nexus and Pixel devices directly to end users, but given how Android is designed, Google cannot simply push out arbitrary security updates to all Android devices.
The problem is that OEMs and carriers are responsible not only for pushing out the updates but also for displaying the latest month for which Google’s monthly updates have been applied to a device. There may be legitimate reasons why an OEM or carrier may choose not to push out a security update for a particular type of device. For example:
The user interface on Android devices shows only the latest month for which patches have been applied. Each month’s updates may include several patches. For legitimate reasons, like the ones discussed above, an OEM or carrier may not include 100% of the patches in a given monthly update. Now, it’s unclear what exactly should be displayed in the device’s user interface when this happens. OEMs and carriers may choose to display the latest month for which they’ve deployed all patches that they reasonably could have in the given timeframe.
However, it appears that some low-end device manufacturers have been simply updating the security patch level displayed on a device rather than actually testing and deploying the updates, which is significantly more expensive. It reminds me of the Volkswagen emissions scandal, where they chose to detect when a car’s emissions were being tested and adjust the emissions rate rather than build cleaner engines. This was the cheaper, easier option.
Google should have designed Android in a way that would have allowed it to push out security updates directly to all devices. It would have resulted in OEMs having less freedom in how they could customize devices, but it would have been much better from a security perspective. Google could have also designed the Android user interface so that details about whether individual patches have or have not been installed are displayed instead of a single patch level. This latter approach would at least allow honest device manufacturers to indicate that they were not able to include a particular patch in a release for a legitimate reason.
OEMs should plan for the costs associated with supporting and updating devices for at least two years after release. This is a nontrivial activity, and processes should be in place for handling this. The processes currently in place are obviously not a good approach.
End users should know that when they purchase a low-end device from a little-known manufacturer, they may not be getting the same level of support and security updates that they would from a high-end device. Additionally, low-end devices are not always cheaper simply because of cheaper hardware components; they may also be cheaper owing to the manufacturer not spending a lot of effort on software updates.
Keep in mind that high-end devices are not supported indefinitely; you should keep an eye on whether your device is currently supported and getting the latest security updates.
Amit Sethi is a principal consultant at Synopsys. He specializes in mobile security, online game security, and cryptography. Amit’s work includes extracting cryptographic keys from embedded devices using side-channel attacks, designing mechanisms to make those attacks more difficult, and designing a format-preserving encryption algorithm based on well-studied cryptographic primitives for a Fortune 500 company. Even in his free time, Amit enjoys reverse engineering binaries, analyzing open source software, and experimenting with new technologies.