Google, Qualcomm partner to bring 4 OS Android updates to new chipsets

More than three years ago, Google announced Project Treble, a major redesign of Android to speed up software updates. While the architecture introduced by Project Treble has helped OEMs accelerate the delivery of major Android OS updates and monthly security patches, it has negatively impacted SoC providers such as Qualcomm. In fact, Treble has increased the complexity and thus the technical costs associated with providing support for Android OS updates for a particular chipset. That has limited the length of support Qualcomm can provide for its SoCs, but that will change soon. All Snapdragon SoCs launched with Android 11 or higher – starting with the Snapdragon 888, Qualcomm supports four Android OS versions and four years of security updates. That’s an extra year than before for their flagship 800 series chipsets.

Today’s announcement is important, but it cannot be understood without the background knowledge of what Google tried to achieve with Project Treble three years ago.

Treble created a split between the Android OS framework (including all UI code, APIs, and system processes that apps interact with) and device-specific low-level software (including the underlying Linux kernel and hardware abstraction layers, or HALs). The low-level device-specific software communicates with the Android OS framework through a well-defined, stable vendor interface. Each Android OS version guarantees backward compatibility with the vendor implementation, which Google guarantees through the use of the vendor test suite (VTS), a standardized compliance test suite. This means that the Android 11 OS framework is, for example, backward compatible with the vendor implementation designed for Android 10. In fact, for each new Android release, Google publishes Generic System Images (GSIs), system images created by the source that are backward-compatible. with the latest 3 versions of supplier implementations. When an OEM builds a new Android device, they are free to modify the Android OS framework to introduce new proprietary features and APIs, but they must ensure that the device vendor’s implementation is compatible with the GSI .

The Treble architecture allows the same Android OS framework code to be reused for various vendor implementations. That’s the “Generic” in Generic System Image. Source: Google.

This is mainly how Treble reduces fragmentation and speeds up delivery of new OS updates – there’s a lot less breakage in linking the Android OS framework (which is open source and provided by Google) and the device-specific, low-level software (which is often closed source and delivered under contracts with SoC suppliers) thanks to the stable supplier interface. Ideally, this means that OEMs can spend less time fixing hardware bugs and more time porting their changes at the system level on top of the latest Android OS release. In fact, since Treble was introduced, Google says OEMs have adopted the latest Android OS release much faster than before. “At the time of Android 11 launch, there were 667 million active users on Android 10, 82% of whom got their Android 10 build via an OTA (Over the Air) update,” said Google.

Acquisition of Android 9 Pie versus Android 10 versus Android 11. Source: Google.

As each new Android release adds support for more hardware features (the operating system must support new features to keep up with the rapid developments in the mobile industry), Google needs to update the vendor interface for that release. So the company defines new HAL requirements and mandates new Linux kernel versions, but they just need devices launch with the new Android OS release to actually support these changes affecting the vendor. For example, if Google adapts Android’s camera HAL to support multiple rear camera sensors, only new devices launched with the new Android version should support updated HAL, while older devices upgrading to the new release can use their older vendor implementation. reuse without this new camera HAL requirement. This reduces the cost and complexity – from an OEM’s perspective – of bringing a new Android OS release to an older device. The problem, however, is that this approach brings additional complexity for SoC vendors such as Qualcomm, MediaTek and others.

As a result of this design principle, Qualcomm and other SoC vendors must support multiple combinations of Android OS framework software and vendor implementations. A SoC vendor supporting 3 generations of Android OS versions for a particular chipset must support 6 combinations of OS framework software and vendor implementations. That’s because OEMs can get away with reusing an older vendor implementation to bypass new HAL and Linux kernel version requirements, SoC vendors need to make sure their vendor implementations support both the old and new requirements. They cannot choose. Multiply that by the dozens of chipsets a SoC vendor has to support and you can see how Treble has actually increased complexity for them.

For this reason, Qualcomm and other SoC vendors generally only offer up to 3 OS letter upgrades and 3 years of security updates for a given chipset. While I am not aware of the exact cost, I assume it is not economically feasible for SoC vendors like Qualcomm to support chipsets for much longer. We’ve seen Qualcomm and other SoC vendors offering longer support at times, but that depends on OEM demand to make it economical. If no such demand exists, OEMs will suffer from the development costs of putting out a new Android release – and it’s not easy. But thanks to the combined efforts of Google and Qualcomm, the latter now supports 4 Android OS versions and 4 years of security updates for select Snapdragon chipsets, starting with the Qualcomm Snapdragon 888.

To make this possible, Google has extended Project Treble’s “no-retroactivity principle” to SoCs next to devices. This means that new requirements for the HAL and Linux kernel version will not apply retroactively to SoCs. For example, a SoC starting with Android 11 (such as the Snapdragon 888) can reuse the same vendor implementation to support Android 12 through Android 14. SoC vendors can thus develop a single Board Support Package (BSP) for a particular chipset. to distribute to OEMs, instead of maintaining multiple versions of the BSP that must be updated with each new Android release. This drastically reduces the technical costs associated with supporting Android on a particular chipset, allowing SoC vendors such as Qualcomm to support their chipsets for longer.

Google is also working with Qualcomm to ensure that the latter reuses the same operating system framework software across multiple Qualcomm chipsets, further reducing the number of operating system framework combinations and vendor implementations Qualcomm must support. SoC vendors are currently changing the AOSP framework code and building their own versions of generic system images. For example, Qualcomm’s is referred to as the QSSI while MediaTek’s is referred to as the MSSI. These SoC-specific system images are now guaranteed to be compatible with multiple chipsets and older vendor software, just like Google’s AOSP GSI.

A hypothetical software support timeline for a SoC vendor that implemented the new principles without retroactive effect.

Devices with the Qualcomm Snapdragon 888 are expected to launch very soon, starting with the Xiaomi Mi 11 and Samsung Galaxy S21 series. While we hope the announcement from Google and Qualcomm means that all Snapdragon 888 devices will get 4 years of Android OS and security patch updates, there’s no guarantee it will. OEMs still have to invest significant amounts of money to develop and distribute new OS versions, but it is much more likely now that Qualcomm itself can support Android updates for 4 years. We hope one or more OEMs will take advantage of today’s announcement to announce extensive software support for their future flagship phones with Snapdragon 888. Most OEMs currently only offer 2 years of Android updates, with both Samsung and Google pledging 3 years. That is far too short compared to Apple and has rightly been called out many, many times and will continue to be mentioned until the gap is narrowed.

As for the other SoC vendors, Google is in talks with them to apply this new no-retroactivity principle so that they too can provide comprehensive software support for their chipsets. We don’t have any confirmation from MediaTek or other SoC vendors, but we don’t see any reason they shouldn’t be on board with this idea – at least for new chipsets. According to Google, they usually expect only newly launched SoCs to benefit from these changes, so don’t expect any of your current devices to get extensive software support due to today’s announcement.

This article was updated at 1:50 PM ET on 12/16/2020 to change “devices” in the title to “chipsets” to better reflect where the changes will take effect. Additional information has been added to the article courtesy of Google.