TL;DR: For the Pixel 9 Pro XL, choose a gki kernelsu susfs release labelled for komodo, android14-6.1, the installed 6.1 kernel sublevel, matching Kernel Module Interface generation and a compatible security-patch vintage. Android 16 or 17 does not make this an android16 or android17 kernel. If any match is uncertain, keep the stock kernel.
By the PrivacyPortal team
Last updated July 2026
The Pixel 9 Pro XL remains an android14-6.1 GKI device even when its operating system is Android 16 or 17. GKI means Generic Kernel Image: Android separates a common kernel from device-specific vendor modules through a stable Kernel Module Interface, or KMI. In practice, successful KernelSU and SUSFS installation depends on the running kernel—not the Android marketing version. Back up everything before proceeding. Unlocking the bootloader wipes the phone, custom kernels can cause boot failure, over-the-air updates may stop working normally, and banking, wallet or Play Integrity-dependent apps may reject the device.
How to Choose a Compatible GKI KernelSU/SUSFS Release for the Pixel 9 Pro XL
A compatible release must satisfy several fields at once. Finding “Pixel 9”, “Android 16” or “kernel 6.1” in a filename is not enough. Confirm the device codename, GKI branch, full kernel release, KMI generation, build vintage and expected root manager.
The definitive rule is simple: match what the phone reports, then follow the release maintainer’s documented compatibility range. Do not infer kernel compatibility from the Android version shown in Settings.
The Pixel 9 Pro XL, codename komodo, uses the android14-6.1 GKI lineage even when Android 16 or Android 17 is installed.
Image caption: A Pixel 9 Pro XL terminal view showing komodo, its 6.1 kernel release and Android security-patch properties.
What each release label means
| Field | Pixel 9 Pro XL requirement | Why it matters |
|---|---|---|
| Device | komodo or an explicitly supported Pixel 9-series package | A package for another Pixel may contain different boot packaging, hooks or vendor expectations. |
| GKI branch | android14-6.1 | This identifies the kernel lineage. It does not change merely because the phone receives Android 16 or 17. |
| Linux release | The installed 6.1.x sublevel or the maintainer’s stated compatible range | Vendor modules and backported patches can behave differently across releases. |
| KMI generation | Match the generation reported by the installed build | The KMI controls compatibility between the generic kernel and device-specific modules. |
| Patch vintage | Built for the same or explicitly supported monthly update family | Google’s monthly kernel changes may invalidate an older prebuilt image even when both say 6.1. |
| Root implementation | The exact KernelSU, KernelSU Next or SukiSU Ultra family named by the release | Managers, kernel drivers and SUSFS userspace components are not freely interchangeable. |
| Artifact type | A boot image or installer explicitly documented for komodo | Flashing an archive, raw kernel image or boot image to the wrong partition can prevent booting. |
Why Android 16 does not mean an android16 kernel
Android’s platform version and its kernel branch are separate versioning systems. The Pixel 9 Pro XL launched on the android14-6.1 GKI family. A later operating-system update can replace apps, framework components and many system partitions while retaining that kernel lineage.
Use the official Android Generic Kernel Image documentation to understand the separation between the common kernel and vendor modules. A download labelled “android16-6.1” is not automatically appropriate merely because Settings reports Android 16.
This naming trap is one of the most common causes of failed gki kernelsu susfs installations. The branch printed in a release name should agree with the kernel information collected from the phone and with the maintainer’s Pixel 9 Pro XL support notes.
KernelSU and SUSFS are separate layers
KernelSU provides root access through code integrated into the kernel. SUSFS adds kernel-level mechanisms for controlling how selected filesystem mounts and related state appear to applications. A KernelSU or Magisk-style module bearing the SUSFS name is usually a userspace control layer; it cannot manufacture missing kernel support.
If the manager or SUSFS WebUI reports “SusFS not supported”, installing more modules is not the fix. The running kernel lacks the required SUSFS implementation, the userspace component does not match it, or the feature was disabled by the builder.
SUSFS requires kernel-side support; installing its userspace module alone does not patch an unsupported stock kernel.
Standard KernelSU, KernelSU Next and SukiSU Ultra should be treated as different root stacks. Select the manager APK and companion components specified by the kernel maintainer. A newer manager is not necessarily safer or compatible with an older kernel driver.
SUSFS can reduce exposure of root-related filesystem state, but it does not make an unlocked or modified phone equivalent to a stock trusted device. Detection changes frequently, and some configurations may detect SUSFS itself.
A practical release-selection framework
Use this order when comparing downloads:
- Reject the wrong device. The release must name komodo or explicitly document Pixel 9 Pro XL support.
- Reject the wrong branch. For this phone, look for android14-6.1 rather than a branch guessed from the installed Android version.
- Compare the complete release. Match the 6.1 sublevel and any android14 generation suffix shown by the phone, unless the maintainer lists a tested range.
- Compare update dates. Prefer a build tested against the same monthly Pixel update. Do not assume an image from several security patches ago remains compatible.
- Confirm the root family. Use the KernelSU, KernelSU Next or SukiSU Ultra manager named in the release instructions.
- Confirm SUSFS inclusion. Look for an explicit statement that SUSFS is compiled into the kernel. A module download by itself is not evidence.
- Confirm recovery. Obtain the matching stock Google factory image before modifying anything. Stop if the correct restore files cannot be identified.
The official KernelSU installation guide explains the supported installation models. Community kernels may add their own packaging, so their release-specific instructions take precedence over a generic flashing command.
Image caption: A compatibility checklist comparing the phone’s android14-6.1 release, KMI generation and patch date with a candidate kernel package.
How to install and verify a compatible release
These steps apply to your own Pixel 9 Pro XL. Read the selected release instructions in full before unlocking or flashing. If its partition, supported build or recovery procedure is ambiguous, do not install it.
- Back up the phone. Copy photographs, authenticator recovery codes, messages, documents and app data somewhere independent. Follow our Android backup guide before rooting. Bootloader unlocking performs a factory reset, and recovery attempts can erase data again.
- Install current platform tools. Use Google’s current Android SDK Platform-Tools rather than an old third-party ADB or Fastboot bundle. Enable Developer options, USB debugging and OEM unlocking. Confirm that adb devices identifies the phone.
- Record the baseline. Run adb shell getprop ro.product.device, adb shell uname -r, adb shell cat /proc/version, adb shell getprop ro.build.version.security_patch and adb shell getprop ro.vendor.build.security_patch. Save the complete output. The device property should report komodo.
- Download recovery material. Obtain the factory image matching the phone’s installed build. Keep its stock boot-related images and flashing documentation available on another computer or drive. Do not rely on files stored only on the phone.
- Select the gki kernelsu susfs package. Compare every field from the selection framework with the release notes. Use the manager, kernel and SUSFS userspace component named in the appended “Modules, apps & files to try” section only when they match those notes.
- Verify the download. Prefer a documented maintainer release with source history and published checksums. Check the checksum when supplied. The Wild Kernels GKI KernelSU/SUSFS releases illustrate the sort of branch, feature and manager information that should be reviewed; their presence does not make every asset compatible with komodo.
- Unlock the bootloader if required. Reboot with adb reboot bootloader, verify the connection with fastboot devices, then use fastboot flashing unlock and confirm on the handset. This immediately wipes user data. Unlocking may affect support or warranty handling, although it does not remove UK statutory consumer rights.
- Flash only by the documented method. If the maintainer supplies a komodo-compatible boot image and explicitly instructs direct flashing, the usual pattern is fastboot flash boot exact-release-file.img, followed by fastboot reboot. Use the real downloaded filename. If the release instead supplies an installer archive or requires a kernel flasher, follow that method; never rename an archive to boot.img or guess a partition.
- Verify the kernel before adding modules. After booting, rerun adb shell uname -r. Open the matching KernelSU-family manager and confirm that the kernel integration is reported as working. Check its log for version mismatch or unsupported-driver messages.
- Verify SUSFS independently. Install only the userspace component specified for that build. Its status page should report kernel-side SUSFS support. Test ordinary calls, Wi-Fi, Bluetooth, cameras and biometrics before installing any further root modules.
- Reboot and test important apps. Check work profiles, streaming apps and any banking or wallet apps you depend on. No configuration can be promised to pass a particular app’s checks. If an essential app refuses to run, return to stock or use that service on an unmodified device.
Wild Kernels GKI KernelSU SUSFS r6 release notes direct users to a KernelSU Next manager CI workflow, demonstrating why the manager must be selected from the kernel release’s own instructions.
Real failure modes and what they mean
- Boot loop immediately after flashing: suspect the wrong branch, sublevel, KMI generation, packaging or patch vintage. Restore the matching stock image; do not repeatedly flash neighbouring versions.
- KernelSU says unsupported: the flashed kernel lacks the expected driver, the wrong manager family is installed, or the custom image was not actually written to the active slot.
- SUSFS WebUI says unsupported: kernel-side SUSFS is absent or incompatible. Another userspace module will not solve it.
- Wi-Fi, camera or sensors fail: the generic kernel is not cooperating with the installed vendor modules. Return to stock even if Android reaches the home screen.
- Phone works until an OTA: the update may have switched slots or replaced the custom boot image. Never reflash the old kernel automatically after a monthly update; repeat the compatibility checks.
- Wallet or banking behaviour changes: app attestation and risk policies are independent of basic root functionality. Root hiding is not a guarantee of compatibility.
A temporarily booting phone is not proof of compatibility. In practice, mismatches sometimes appear only when a vendor module loads, the device enters deep sleep or the next over-the-air update activates the other slot.
Image caption: A recovery screen illustrating the choice between restoring the stock boot image and retrying an unverified custom kernel.
Security, OTA and recovery considerations
An unlocked bootloader weakens protection against physical tampering because the device can boot software that Google has not signed for that phone. Root also gives approved applications unusually powerful access. Install as few modules as possible, review their source and remove abandoned components.
Pixel phones use A/B slots for safer updates. An OTA can place a new system and kernel on the inactive slot, then switch to it. Root may disappear, or a stale custom-kernel workflow may create a mismatch. Capture the new kernel details after every update and wait for a release explicitly tested with that build.
Do not relock the bootloader while custom or mismatched images remain installed. Relocking against an invalid software state can make recovery harder. Restore a complete compatible stock build, verify normal booting and follow Google’s documented process before considering relocking.
If experimenting with kernels is not suitable for a daily-use handset, a supported privacy-first Android phone from PrivacyPortal offers a calmer route to reducing Google dependence without assembling a root-hiding stack yourself.
Frequently asked questions
Which GKI branch does the Pixel 9 Pro XL use?
The Pixel 9 Pro XL uses the android14-6.1 GKI lineage. Its codename is komodo. Installing Android 16 or Android 17 does not by itself change that lineage to android16 or android17.
Can I choose any android14-6.1 KernelSU image?
No. Match the device support, Linux 6.1 sublevel, KMI generation, security-patch vintage, root implementation and artifact type. Use the maintainer’s tested compatibility statement rather than matching only the broad android14-6.1 label.
Does the SUSFS module work with the stock Pixel kernel?
Not by itself. SUSFS requires support compiled or patched into the running kernel. Its companion module or WebUI controls that support but cannot add the missing kernel implementation.
Should I use KernelSU, KernelSU Next or SukiSU Ultra?
Use the family required by the compatible kernel release. Each can work in an appropriate build, but managers and kernel drivers should not be mixed casually. Standard KernelSU may be more conservative in some configurations, while forks may integrate additional SUSFS features.
Will KernelSU and SUSFS make banking apps work?
There is no reliable guarantee. Banks, wallet providers and other apps can examine Play Integrity results, bootloader state, filesystem behaviour and their own risk signals. A setup that works today may fail after an app, server-side policy or Android update.
What should I do after a Pixel monthly update?
Allow for the possibility that the update replaces the custom kernel or switches slots. Record the new kernel release and patch dates, then wait for a gki kernelsu susfs build explicitly compatible with that update. Do not automatically reuse the previous month’s image.
What is the safest choice if a release label is unclear?
Keep or restore the stock kernel. An ambiguous filename, an unsupported claim in a chat message or a partial version match is not enough evidence to flash a boot-critical image.
