Here’s how Google is making it easier for Android devices to get 7 years of updates

Nobody wants to get rid of a perfectly functional smartphone, but unfortunately, the phone update policies of many Android manufacturers make it risky to keep using one after a few years. Fortunately, there’s a recent trend in the industry towards extending software support, with some of the best Android phones now getting up to 7 years of updates. However, not many companies are offering this level of support, but Google is hoping to change that with its new Longevity GRF program.

What is GRF?

GRF, which stands for Google Requirements Freeze, is the name of a program that Google launched in 2020 to make it easier for chipset vendors like Qualcomm and MediaTek to support 3 years of Android OS updates. GRF makes good on the promise of Project Treble, an architectural change that Google introduced in 2017 that modularized Android to separate the OS framework from lower-level vendor and Linux kernel software. The problem with Project Treble is that while it made it easier for OEMs to support Android OS updates, it actually increased the complexity for chipset vendors. This is because chipset vendors now had to support both devices that launched with the original version of Android that the chipset’s vendor software was built for as well as devices that launched with newer versions of Android.

To solve this, Google committed to freezing its vendor software requirements so they would no longer be retroactive, hence the “Freeze” in Google Requirements Freeze. Instead of requiring OEMs to ship updated vendor software with each Android OS update they wanted to roll out, OEMs could now ship Android OS updates with the original vendor software that the chipset was built for.

Essentially, OEMs could reuse the chipset’s vendor software across multiple versions of Android and still receive certification from Google. This meant that chipset vendors like Qualcomm and MediaTek wouldn’t have to update their vendor software to meet new vendor software requirements for at least 3 years after launch, reducing the engineering costs associated with supporting multiple different combinations of vendor software and Android OS versions. Thanks to GRF, chipset vendors could save a lot of money by only having to support 4 Android OS/vendor software combinations as opposed to 10 if they wanted to support 3 years of updates.

GRF is an immensely complicated subject, but that’s the gist of it. If you want to know more about GRF, I highly recommend reading this deep dive I wrote on the program a few years ago.

What is Longevity GRF?

You’ll notice, however, that GRF only allows the vendor software to be reused for 3 Android version updates. At the beginning of this article, though, I mentioned how Google wants to enable 7 years of Android version updates, something that isn’t enabled under the current GRF program terms. If an OEM wanted to deliver a fourth, fifth, sixth, or even seventh Android OS version update to a device with a chipset that’s under GRF, the OEM would have to either pay the chipset vendor for extended support or undertake the colossal engineering effort of updating the chipset’s vendor software themselves to meet Google’s updated vendor software requirements for each subsequent release.

It isn’t unheard of for an OEM to do that, as there are multiple Samsung devices eligible for 7 major Android updates even though they’re using chipsets that are under the GRF program, but it’s very difficult and costly to do so. Google wants more OEMs to support 7 years of OS updates like Samsung and they themselves do, though, which is why it created the new Longevity GRF program.

Longevity GRF allows for a chipset’s vendor software to be reused for 7 Android version updates instead of 3. That means that a device launching with a chipset whose vendor software was built for, say, Android 15 can reuse that vendor software when it updates to Android 16 through 22. The recently announced Qualcomm Snapdragon 8 Elite is the first chipset under the Longevity GRF program, which means that all the upcoming phones powered by it will be eligible to reuse the vendor software that Qualcomm originally built for it for 7 Android version updates after the chipset’s launch.

However, there’s a catch: OEMs will have to upgrade the Linux kernel version after 3 years. A minor kernel update won’t suffice, either, as Google will require OEMs to ship a major kernel version upgrade in order to receive certification. The reason for this is that Google is only committing to a four-year support lifetime for its Linux kernel forks, starting with kernel 6.6 which is the version that new chipsets built for Android 15 are required to launch with. If Google didn’t force OEMs to ship major kernel version upgrades, then OEMs would have to backport security patches themselves to ensure they’re compliant with Android’s security requirements. Backporting patches can be problematic, though, because not every patch included in a Linux kernel release is marked as a security patch, so some necessary patches may be missed during the backporting process.

In addition, Google won’t let OEMs ship new devices running Android versions that are four versions newer than what the vendor software was originally built for. This is so OEMs don’t ship devices that’ll only benefit from 2 or 3 of the 7 Android version updates that Longevity GRF enables.

With all that in mind, here’s what the Android support lifecycle looks like under Google’s Longevity GRF program.

Although Longevity GRF makes it easier for OEMs and silicon vendors to support 7 Android OS version upgrades, it also disincentivizes supporting new hardware features added in new versions of Android. For example, the 2G toggle that Google added in Android 12 and the flashlight brightness API Google added in Android 13 both require updates to the vendor software to support. That means that devices upgrading to Android 12 or 13 with vendor software frozen at Android 11 wouldn’t be able to support either feature. This was already a problem under GRF but will now be exacerbated by Longevity GRF due to the longer lifecycle that it covers.

Google announced this Longevity GRF program at an event for OEMs earlier this year, but it hasn’t publicly shared any details on it. I learned about it thanks to a source who wishes to remain anonymous. The charts that I embedded in this article are recreations of charts that Google showed off to OEMs, so they should accurately demonstrate how Longevity GRF impacts the Android support lifecycle for chipsets covered under the program. Still, since Google hasn’t revealed the program publicly, there’s a chance I’m missing some details. If I learn any additional information about the program, I’ll be sure to update this article.