Google’s Latest Attempt at Speeding up Android Updates is a Double-Edged Sword

Every year, millions of people discard perfectly good smartphones when they upgrade to a new model. Sure, there are ways to repurpose old phones rather than discard them, and there are also ways to recycle them rather than throw them away. But not everyone has a reason to keep an old phone around, and recycling opportunities aren’t always available. Smartphones contribute to 12% of global e-waste because of how many of them are manufactured and shipped each year to consumers, who are basically forced to upgrade because the software became obsolete.

Earlier this week, a reporter for Vice published a scathing article criticizing Google for “forcing” him to “dump a perfectly good phone” because continuing to use it past its EOL date would put him at risk of security vulnerabilities. The phone in question was a Pixel 3, Google’s flagship released in late 2018. Google only committed to delivering three years of security and OS updates to the Pixel 3 since its release, so the phone is no longer guaranteed to get any more Android version updates or security updates. Google told Vice that this three-year update commitment “provides users with a great experience for their device,” a statement that many people understandably took issue with considering that Google has been touting the Pixel 6’s extended security support period of five years.

Although Google never explicitly stated it, many people attribute the Pixel 6’s extended support to Google’s decision to use its new Tensor chip instead of a Qualcomm chip. The logic is that the SoC vendor dictates the software support length of a chipset, as they’re best equipped to provide updates to drivers and other proprietary vendor components. Since Google designed the Tensor chip, they aren’t reliant on Qualcomm for driver updates, which means they can theoretically support their chipset for as long as they’re willing. The switch to Tensor may be the cause of some of the software issues in the Pixel 6’s first few updates, but in the long run, it’s better that Google made the switch, as they need to set the standard for other OEMs to follow.

But what about those other OEMs? Most OEMs can’t spin up their own silicon design teams, so they’re stuck with off-the-shelf chipsets designed by companies like Qualcomm or MediaTek. Neither Qualcomm nor MediaTek are in the business of selling smartphones (no, that “Smartphone for Snapdragon Insiders” doesn’t count because it’s an ASUS phone in everything but name). Their goal is to sell chips, so it doesn’t matter to them if an OEM who buys their product only offers one, two, or three years of software updates to end users. SoC vendors provide their licensees with a few years of software support, but exactly how long those chips are supported depends on how popular they are and how much OEMs are willing to pay. If the SoC vendor isn’t making money from the chip, then there’s no incentive for them to keep supporting it.

So, what can Google do to make SoC vendors support their chipsets for longer? The most drastic action they could take is to add a clause to their GMS licensing agreements that mandates OEMs to provide a minimum level of support, which would in turn force OEMs to work with (pay) SoC vendors for extended support. It’s predictable how this would turn out (it’d be a disaster), so we’ll call this the nuclear option. The more realistic option that Google has at their disposal is to make updating easier, which would reduce how many engineering man-hours are spent on updates (and thus make them less expensive to do). That’s pretty much the reason behind every one of Google’s projects to fix Android updates, whether it be Project Treble, Project Mainline, the Generic Kernel Image, or more recently, Google Requirements Freeze.

Google Requirements Freeze, or GRF for short, is the name of the project designed to reduce the engineering costs of providing Android OS software support for a chipset. You could say that the work started by Google in 2017 with Project Treble has finally been completed with Google Requirements Freeze. Thanks to GRF, SoC vendors no longer need to update their side of the software to match each Android OS version they plan to support. But this has its downsides, as I’ll point out in this week’s edition of Android Dessert Bites.

Google finally finishes Project Treble

Before I can describe the architectural changes introduced with GRF, I need to explain the architectural changes introduced by Project Treble. Rather than retread old ground, though, I’ll instead point to the sixth edition of Android Dessert Bites, where I dedicated an entire section to explain how Google rearchitected Android with Project Treble. If you aren’t familiar with Treble, then I recommend you start there, because I even provided an analogy in that post that explained Treble in a way that anybody can understand.

One of the most important takeaways from my previous post is that AOSP maintains backward compatibility with older vendor implementations. This means that, as an example, the Android 12 OS framework is backward compatible with the vendor implementation designed for Android 11. Treble wouldn’t be very useful if Google only guaranteed backward compatibility for a single release, though. Instead, Google guarantees that each Android OS version is backward compatible with the last three versions of vendor implementations. This way, OEMs can focus on implementing their custom OS features instead of spending time fixing bugs with hardware.

Speaking of hardware, with every new Android release, Google adds some new hardware features that require HAL updates. For example, Android 12 added a new API that lets device owner apps disable USB data signaling. This API isn’t available unless USB HAL 1.3 is implemented on the device, though Google recommends adding support because it improves the security of enterprise devices. If Google wanted to, say, require that all devices launching with Android 12 support this feature, they’d need to mandate that those devices implement USB HAL 1.3. It’d be optional for devices upgrading to Android 12 to implement this HAL, because in this hypothetical, the feature would only be required for devices launching with Android 12. Remember that Google guarantees that new Android OS frameworks are backward compatible with the last three versions of vendor implementations — meaning that Google can’t force upgrading devices to support new HAL versions, as it’d break Treble’s contract.

From a SoC vendor’s perspective, this was a nightmare to deal with. SoC vendors are largely responsible for updating the vendor implementation, so if Google defined a new HAL requirement or mandated a new Linux kernel version, the SoC vendor had to update their chipset’s vendor implementation so it would be compliant with the requirements for both the old and new Android version. That’s because an OEM could choose to launch a device on the same Android version that the chipset initially supported (N), or they could choose to launch it on the N+1, N+2, or N+3 release. Because of this, SoC vendors had to support multiple combinations of Android OS framework software and vendor implementations. If, say, the SoC vendor planned to support N to N+2 versions, then they’d have to support six combinations of Android OS framework and vendor implementations. Then consider that SoC vendors had to do this across multiple chipsets, and it’s easy to understand how Project Treble actually made updates more complicated (and thus more expensive) for them.

Enter Google Requirements Freeze, a program Google introduced in late 2020 to eliminate this complexity. Under GRF, Project Treble’s “no-retroactivity principle” was extended to SoCs. Google now ensures that vendor implementations built against version N will be certifiable for up to version N+3. In other words, Google committed to freezing its new HAL and Linux kernel version requirements so they’d no longer be retroactive.

For example, if an SoC initially launched with support for Android 11, then its vendor implementation could be “frozen” at that release. When upgrading to Android 12, 13, or 14, that device could then reuse the vendor implementation designed for Android 11 and still pass certification tests.

This cut down on the complexity of maintaining Board Support Packages (BSPs) for a particular SoC, significantly reducing the engineering costs of supporting Android on a particular chipset. As a result, Qualcomm now supports up to N+3 Android releases and four years of security updates for chipsets under the GRF program. Previously, Qualcomm typically offered support for up to N+2 Android releases and three years of security updates, so GRF enabled Qualcomm to update its BSP for an additional year.

If OEMs actually take advantage of this extended software support to provide their users with an extra letter upgrade and another year of security updates, then it’d give users a reason to hold onto their devices for longer, reducing the yearly e-waste from discarded smartphones. There’s no guarantee that OEMs will actually do this, but there is momentum in the industry pushing them to do this. However, the extra year of updates comes at a cost, but before I can dive into some of the issues with GRF, I need to explain one more thing.

What is a BSP?

A BSP is a package containing the source code and prebuilt binaries needed to get Android up and running on a particular chipset. For example, BSPs contain the drivers and HALs needed for Android to communicate with your device’s hardware, and it also contains a fork of AOSP with proprietary additions from the SoC vendor (typically performance-related libraries).

OEMs don’t get the source code for everything needed to run Android on a particular chipset, but there’s enough there for them to update many HALs on their own if they wanted to. Before GRF, they had no need to, because SoC vendors were already doing all that work. After GRF, though, it’s entirely up to OEMs to update HALs, because the SoC vendor will be content with leaving the vendor implementation “frozen” as Google allows.

So, in all likelihood, most OEMs will ship Android version updates without an updated vendor implementation to accompany it, and that’s exactly what we’re seeing with most devices that have updated to Android 12. Those devices, however, will be missing support for some newly added features in Android 12, which brings us to the first downside of GRF.

The first problem with GRF: Feature stagnation

Earlier, I mentioned that Android 12 added a new API to disable USB data signaling, a security feature that’ll definitely be useful for IT admins managing enterprise devices (if you’re looking to manage a fleet of Android devices, check out Esper’s in-house solution, by the way!). Since this feature requires an update to the USB HAL, any devices shipping with an older vendor implementation won’t support this feature. That’s not even the only security feature that many devices will be missing out on as a consequence of GRF. Android 12’s new toggle to disable the 2G modem requires an update to the radio HAL. Because most Qualcomm chipsets are under GRF, these security features will be missing on a lot of devices upgrading to Android 12.

In essence, any feature that requires a HAL update will likely not be supported on upgrading devices thanks to GRF. Implementing a feature like torch strength control would, for example, require an update to the camera HAL. Even a feature that requires just adding a single line to a HAL will likely be skipped.

GRF also seems to have caused issues with the adoption of new API requirements. A recent code change submitted to the AOSP Gerrit shows that Google was forced to backtrack on mandating the multi-camera API for devices launching with Android 12. The reason is because “certain OEMs’ new S launches with vendor freeze cannot implement multi-camera API.”

GRF has resulted in many devices missing out on new security features, and it’s likely going to result in devices missing out on other new Android features in the future. That’s assuming, of course, those devices even get new Android updates, which brings us to the second downside of GRF.

The second problem with GRF: OEMs are even more reliant on SoC vendors for updates

Let’s say that an OEM wants to provide their users with a fourth letter upgrade, from N to N+4. Because the vendor-side BSP is “frozen” at version N, the OEM would have to port the vendor implementation from N to N+4. They’d have to account for three versions worth of changes in requirements to pass the latest certification tests.

Updating a BSP is not impossible for an OEM to do, but for those chipsets under GRF, the SoC vendor likely won’t provide any support. Google, for example, seems to update Qualcomm’s vendor software on its own, as the company’s Snapdragon 765G-powered smartphones seem to have a vendor image built for API level 31, even though Qualcomm froze the vendor implementation of that chipset at API level 30.

GRF might have reduced the technical burden on SoC vendors, but it makes it harder for OEMs to extend software support beyond what the SoC vendor provides.

It’s too early to say how much of an impact the Google Requirements Freeze program has had on Android updates, but I’m certain that it will result in an increase in the average upgrade cycle of phones. After all, Google’s own data showed that Project Treble resulted in the faster uptake of new Android releases, and Treble wasn’t even complete until GRF!

Unfortunately, I’m concerned that, without support from the SoC vendor, many OEMs won’t update HALs, resulting in feature stagnation. We’ve already seen this happen with some of Android 12’s new security features, and I’m worried that it’ll happen again with the new hardware features in Android 13. Once Google publishes the documentation for Android 13 later this year, we’ll find out just what features most upgrading devices will miss out on.

Thanks for reading this week’s edition of Android Dessert Bites. GRF has had a monumental impact on Android updates, but Google’s lone blog post on the subject only vaguely explains the architectural changes. Google’s blog post didn’t even announce the name of the program, which I myself only found out thanks to some help from a friend! 

Esper Device Management