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. more text at link