Over 3 years ago, Google announced Project Treble, a major rearchitecting of Android designed to speed up software updates. While the architecture introduced by Project Treble has helped OEMs to speed up the delivery of major Android OS updates and monthly security patches, it has had an adverse effect on SoC providers like Qualcomm. In fact, Treble has actually increased the complexity, and thus the engineering costs, associated with providing Android OS update support for any given chipset. That has limited the length of support that Qualcomm can provide for its SoCs, but that will soon change. All Snapdragon SoCs launching with Android 11 or later—starting with the Snapdragon 888, Qualcomm will support 4 Android OS version updates as well as 4 years of security updates. That’s an additional year than they previously provided for their flagship 800-series chipsets.
Today’s announcement is significant, but it cannot be understood without the background knowledge of what Google tried to accomplish with Project Treble 3 years ago.
Treble created a split between the Android OS framework (including all the 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 device-specific, low-level 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 ensures through the use of the vendor test suite (VTS), a standardized compliance test suite. This means that, for example, the Android 11 OS framework is backward compatible with the vendor implementation designed for Android 10. In fact, for each new Android release, Google publishes Generic System Images (GSIs), source-built system images that are backward-compatible with the last 3 versions of vendor 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’s vendor implementation is compatible with the GSI.
Thanks to the Treble architecture, the same Android OS framework code can be reused across different vendor implementations. That’s the “Generic” in Generic System Image. Source: Google.
This is primarily how Treble reduces fragmentation and speeds up the delivery of new OS updates — there’s a lot less breakage when pairing 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 provided under contracts with SoC vendors) thanks to the stable vendor interface. Ideally, that means OEMs can spend less time fixing bugs with hardware and more time porting their system-level changes on top of the latest Android OS release. In fact, since Treble was introduced, Google says that OEMs have adopted the latest Android OS release much more quickly than before. “At the time Android 11 launched there were 667M active users on Android 10, 82% of whom got their Android 10 build via an over the air (OTA) update” said Google.
Adoption of Android 9 Pie versus Android 10 versus Android 11. Source: Google.
Because each new Android release adds support for more hardware features (the OS needs to support new features to keep up with the rapid advancements of the mobile industry), Google needs to update the vendor interface for that release. The company thus defines new HAL requirements and mandates new Linux kernel versions, but they only require devices launching with the new Android OS release to actually support these vendor-impacting changes. For example, if Google modifies Android’s camera HAL to support multiple rear camera sensors, only new devices launching with the new Android version have to support that updated HAL, while older devices upgrading to the new release can reuse their older vendor implementation 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 introduces additional complexity for SoC vendors like Qualcomm, MediaTek, and others.
As a result of this design principle, Qualcomm and other SoC vendors have to support multiple combinations of Android OS framework software and vendor implementations. An SoC vendor that supports 3 generations of Android OS versions for a particular chipset has to support 6 combinations of OS framework software and vendor implementations. That’s because while OEMs can get away with reusing an older vendor implementation to sidestep new HAL and Linux kernel version requirements, SoC vendors have to ensure their vendor implementations support both the old and the new requirements. They don’t get to pick and choose. Multiply that by the dozens of chipsets that an SoC vendor has to support and you can see how Treble has actually increased complexity for them.
It’s for this reason that Qualcomm and other SoC vendors generally only provide a maximum of 3 OS letter upgrades and 3 years of security updates for a particular chipset. Although I’m not privy to the exact costs, I presume it’s not economically feasible for SoC vendors like Qualcomm to support chipsets for much longer than that. We’ve seen Qualcomm and other SoC vendors sometimes provide support for longer, but that depends on demand from OEMs to make it economical. If no such demand exists, then it falls on OEMs to bear the brunt of development costs to bring up a new Android release — and that’s not an easy feat. But thanks to the combined efforts from Google and Qualcomm, the latter will now support 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 in addition to devices. This means that new HAL and Linux kernel version requirements won’t be retroactive for SoCs. So, for example, an SoC that launches with Android 11 (like the Snapdragon 888) can reuse the same vendor implementation to support Android 12 through Android 14. This dramatically reduces engineering costs associated with supporting Android on a particular chipset, giving SoC vendors like Qualcomm the ability to support their chipsets for longer. Google is also reusing the same OS framework software across multiple Qualcomm chipsets, further lowering the number of OS framework and vendor implementation combinations that Qualcomm has to support.
A hypothetical software support timeline for an SoC vendor that has implemented the new no-retroactivity principles.
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 Google and Qualcomm’s announcement means all Snapdragon 888 devices will get 4 years of Android OS and security patch updates, there’s no guarantee this will be the case. OEMs still need to invest significant sums to develop and distribute new OS versions — but it’s much more likely to happen now that Qualcomm themselves can support 4 years of Android updates. Here’s hoping that one or more OEMs take advantage of today’s announcement to announce extended software support for their future flagship phones. Most OEMs only offer 2 years of Android updates at the moment, while both Samsung and Google promise 3 years. That’s far too short compared to Apple and has rightfully been called out many, many times and will continue to be called out until the gap is shortened.
The post Google and Qualcomm partner to deliver 4 years of Android updates for new Snapdragon devices appeared first on xda-developers.
from xda-developers https://ift.tt/34jIeQc
via
IFTTT
