Android 6.0 Marshmallow's Patch Date Feature

Nexus 6P Hands ON AH 10

In some corners of the world, the Android ecosystem is sometimes thought of as a wretched hive of scum and villainy, where every other application comes pre-loaded with malware. The truth of the matter is that all operating systems – mobile, laptop, desktop or server – are vulnerable and there is likely to always be an arms race between the gatekeepers of these operating systems, and the poachers, or hackers. When it comes to devices, part of the problem is keeping the operating system and applications protected against known weaknesses. One of Android’s perceived weaknesses is how fragmented the market is and how many different versions of the operating system that are still in service by customers across the world. In the immediate wake of the Stagefright scare stories, Google changed how frequently Android is updated to patch over security vulnerabilities. This is in addition to many applications being available on the Google Play Store, which means if one part of the operating system is discovered to have a vulnerability, it may be patched via the Play Store infrastructure.

With current versions of Android, up to 5.1.1 Lollipop, it is difficult for users to understand if they are on the latest build of their software: Google has given different devices a build code, such as LMY48P (the latest Android build for the 2013 Nexus 7 LTE). However, to most people, this code is meaningless… and Android 6.0 Marshmallow sees this situation redressed with the addition of the Android security patch level field in the Settings menu. This date shows the customer at what point the device has been patched, and Google’s idea is that this date will be inside the last month for currently supported devices, as it has promised to release updates on a monthly basis. Providing the customer has allowed the device to update, and of course it is still supported, this should provide an insight for customers.

There are many “ifs” in the above paragraph. Part of the problem is a lack of customer knowledge: people simply don’t know or even care that their device is a year out of date, because it still works as it did out of the box. Seeing a date may encourage some customers more likely to ask the question of their device manufacturer or carrier, compared with seeing a build reference or Android version number, but many customers are likely to shrug their shoulders if they see that their device’s software is six months old. The other part of the problem is that whilst Google can release security patches, it is then up to the manufacturers to incorporate these changes to their device software. Once this is done, it’s then up to the carrier to test these changes and once approved, to be released to customer devices in the field. It is also assumed that customers will allow their device to update. However, although a small change, it could encourage manufacturers and carriers to push out more frequent updates – just as we saw with several big name manufacturers rushing to release Android 5.0 Lollipop in front of the competition. Keeping our devices up to date is less about the bragging rights of having the very latest version of Android and more about patching and fixing security vulnerabilities detected in the software. A side effect could be more manufacturers supporting their devices for longer, and this might see more investment in software engineers or it could see manufacturers not using their own custom skins over Android. Whilst it seems difficult to imagine Samsung without the TouchWiz interface, or HTC without Sense, Motorola are a great example of a manufacturer offering a very-near stock experience on their range of devices.