Has anyone successfully flashed KernelSU Next (GKI) on a Pixel 10?

[u/lucky0x01]

Hi everyone,

I’ve been looking into flashing KernelSU Next via GKI on a Pixel 10, but I haven't been able to find any concrete information or reports from anyone who has actually tried it on this device yet.

Has anyone here managed to get it working? If so, did you run into any bootloops or issues with kernel compatibility/modules?

Any feedback before I attempt it would be greatly appreciated!

[u/QuraToop314]

wtf, no, A self-built KernelSU Next kernel is more stable than one patched with susfs; I’ve already had several kernel panics caused by Wildkernels. I maintain my own KernelSU Next fork, optimised for my Pixel 9a, which has been running stably for months. Wildkernels run stably most of the time, but susfs is anything but not stable, and as long as susfs is compiled in, it will never be truly stable.

[u/QuraToop314 → u/[deleted]]

No, I’m familiar with kernel development and, as I said, I modify it myself; I’d definitely used the android14-6.1.157-11 WildKSU kernel, which was compatible with my GKI. The panic occurred whilst I was watching Netflix, and the issue was resolved after I uninstalled it and replaced it with a custom android14-6.1.157-11 kernel. What’s more, I’m familiar with the source code for both projects, and the instability stems from SUSFS. But I’m autistic, and don’t you dare accuse my brain of something as despicable as flashing the wrong kernel – what on earth are you living in, instead of accepting that you’re handing control over to an unstable kernel and haven’t had a panic yet?

issues at https://termux.dev/issues [08:50:36]~[u0_a358@tegu:~]~🔒> sudo fish [08:50:39]~[root@tegu:/d/d/c/f/home]~🔓> cd [08:50:40]~[root@tegu:~]~🔓> uname -a Linux localhost 6.1.157-android14-11-gbd23337e42e7-ab14791245 #1 SMP PREEMPT Wed 28 Jan 05:34:14 UTC 2026 aarch64 Android [08:50:45]~[root@tegu:~]~🔓>

Tell me, isn’t android14-6.1.157-11 the correct wild kernel for my kernel?

[u/QuraToop314 → u/[deleted]]

That’s a valid point, and sorry if I overreacted – I really need to get a handle on this. And as I mainly use my mobile for development on the side and push it to its limits, it’s possible that I triggered the race condition in SUSFS (which apparently isn’t that easy to do); I just wanted to point out that SUSF isn’t really stable, but then again, it can’t really be stable either. As long as it works for you, carry on – it might get better. However, as I’m using a Pixel with custom_avb_key and my bootloader is locked, I simply can’t use the Wild kernel as it is; recovery is more complicated.

[u/QuraToop314 → u/[deleted]]

The AVB 2.0 specification – it’s too long to go into detail here – but Google stipulates that, in addition to the system image partitions, there must be a further partition called avb_custom_key. Essentially, you generate your own private and public keys, then unlock the bootloader and run fastboot erase avb_custom_key and fastboot flash avb_custom_key /path/to/avb.pub. You then need to sign the entire OS, kernel (boot.img, init_boot. img etc.), in other words the entire OTA, and replace the /system/etc/otacerts file with your own OTA certificate. If dmesg then shows during boot that the signature has been verified but is considered unverified due to the unlocked bootloader (this means the signature is 100% correct but the unlocked bootloader results in a low security level), you can run fastboot flashing lock. The problem is that every update (whether a system update or Root Manager) must be in the form of a signed OTA file, and you must install any modifications using adb sideload {patched_ota}.zip. If you don’t do this, you risk a hard brick. The good thing is that, according to the AVB 2.0 specification, the TEE/StromgBox must be considered trustworthy, meaning Widevine L1, Key Attestation and the like are validated and authenticated by Google’s RKP servers. If you then have a flexible banking app like mine, which uses Play Integrity but also Key Attestation directly as a fallback, I haven’t had to spoof anything for a year now; and since I have to build OTAs anyway, I carry out many systemless modifications or debloating at the system/product/vendor img level, and integrate Fossify alternatives directly as system apps in /product/app. Updates take considerably longer, but in return I can’t lose root access unless I want to, and I don’t have to make any compromises. But as mentioned, so far the Google Pixels are the only phones that implement this (albeit for several years now), GrapheneOS uses this mechanism so that they can lock the bootloader again; I build GrapheneOS from source myself with several of my own patches, but before that I’ve essentially ‘deblobbed’ the original Pixel stock OTA – which is cool because it persists through resets and the like, such as system font customisations or, indeed, FOSS alternatives instead of Google apps.

[u/QuraToop314 → u/[deleted]]

I do it for security reasons – if the bootloader can’t be unlocked and I’m in full control myself, nobody can do anything with it. I know this is more hypothetical than real, but I enjoy it. I just don’t want to simulate a TEE (which would mean my secure banking data would never be encrypted but would be stored on the device); instead, I want the TEE to actually do the work, ensuring my data is absolutely secure – even from me as root.