🥳

'"TL;DR:
* #Google has upgraded the #kernel version of all Tensor-powered #Pixels in the Android 15 QPR2 Beta 1 release.
* The Google Pixel 6 series, Pixel 7 series, Pixel 8 series, Pixel Tablet, and Pixel Fold all join the Pixel 9 series in running #Linux 6.1.
* Previously, Tensor G1 and G2-powered Pixels were running #LinuxKernel 5.10 while Tensor G3-powered Pixels were running on Linux 5.15.'"

https://www.androidauthority.com/pixel-linux-6-1-android-15-qpr2-3498932/

@kernellogger so actual tldr: my phone would be fine, if they weren't abandoning it for money.

@kernellogger in the end, it really shouldn't be a big effort for the phone OEMs. Google does most of the work with their GKI kernels already.

@mxk are you sure?

I mean, sure, Google will ensure kernel <-> Android Userland will work.

But how hard is it for Android vendors that have huge kernel patches applied to support the hardware? Patches never upstreamed? Patches from a BSP that the chip vendor maybe never forward ported to support newer kernels and/or android versions?

@vathpela you lost me.

So you have a non-Tensor-powered Google phone? Or a Android phone from another vendor?

@kernellogger you don't get patches with GKI.
The kernel image itself is compiled by Google. All the vendor can do is supply kernel modules, which should be "GKI vendor modules" which are using a variant of the kernel module API that is kept stable by Google.
(Ensured through filtered headers used for building those modules)

@mxk you seem to know a lot more than I about this, so allow me to ask:

Is using GKI mandatory these days?

@kernellogger @mxk That's not how Android kernels are working anymore. Vendors can have huge numbers of external kernel drivers/modules (i.e. pixel 6 has 300+ of them), but the "core" kernel is managed by Android/Google, in public, in their GKI kernel branches, and that is what is the "base" of the kernel that all vendors can then add drivers to.

If a vendor wants to change the "core" parts of the kernel, they must either submit the changes upstream for merging first (and then backport the change to the GKI kernel and submit it to Android), or somehow convince Android to take it into their GKI kernel (with reasons why upstream rejected it), or add a "hook" to the GKI kernel so that they can put their changes in a kernel module (like many do for scheduler changes.)

The -lts releases get merged into the Android/GKI kernel branches on a monthly basis, which then gets pushed out to all devices "quickly" as there are no in-kernel-abi breaks between the GKI kernel and all external kernel modules used by vendors.

Android has followed the "old" enterprise kernel module here, with the exception of the hook additions, that companies have used for decades (the abi stability changes were taken directly from RHEL and SLES). It's not exciting kernel work, but allows security fixes to get pushed out to devices MUCH faster which is helping everyone out, AND it has forced the vendors to work upstream to get their features merged properly, which has been happening for years now to much success.

There was a plumbers talk all about this this year (and last, and the year before), if you want more details.

@gregkh @mxk

many thx for the insights! 👍

I sometimes wish I could follow what happens in the Android world more closely, but there are only so many hours in a week… 😟

@kernellogger @mxk Totally understand.

Here's a link to Todd's latest Plumbers conference calling out how they are going to support devices for 7+ years by moving to new kernel versions over time: https://lpc.events/event/18/contributions/1703/attachments/1391/2998/LPC%202024%20-%20Android%20Device%20Longevity.pdf

@kernellogger @gregkh @mxk all this reminds me that I need to go sort some backports...

@kernellogger yeah, pixel 5. It works just fine.

@gregkh @kernellogger @mxk thanks for the links. As someone who just occasionally follows the android part I’m happy to see the details here!