TL;DR: For gki kernelsu susfs, select a build using your device’s complete Kernel Module Interface (KMI), supported ROM type, boot partition and security-patch level—not its displayed Android version. Back up first, retain matching factory images, verify checksums and never flash a package merely because its filename mentions the right Linux version.
GKI KernelSU and SUSFS can provide kernel-level root with stronger filesystem hiding than a userspace-only setup, but compatibility is unforgiving. The safe route is to record the running kernel, confirm the complete KMI and device codename, then use a build explicitly supported by its maintainer for that device and ROM. Unlocking the bootloader wipes the phone. A wrong kernel can prevent booting, break vendor hardware, disrupt over-the-air updates or reduce security. Root can also cause banking, wallet, streaming and workplace apps to fail their integrity checks; no configuration is guaranteed to defeat a particular app’s detection.
By the PrivacyPortal team
Last updated July 2026
GKI KernelSU SUSFS: ABI compatibility and safe build selection
A Generic Kernel Image, or GKI, separates Android’s common kernel from device-specific vendor modules. Those modules communicate with the kernel through the Kernel Module Interface. The relevant compatibility target is the complete KMI generation, commonly represented by an Android kernel branch and Linux family such as android14-6.1, plus any generation or build constraints documented by the device maintainer.
The Android version displayed under Settings is not enough. An Android 15 or Android 16 ROM may retain a kernel branch introduced with an earlier vendor release. Conversely, two phones showing the same Android version can use different Linux families, vendor modules and boot-image layouts.
Read the official Android Generic Kernel Image documentation before treating a kernel as interchangeable.
Android’s GKI documentation defines the KMI as the stable interface between the kernel and vendor modules; compatibility is scoped to a KMI generation, not an Android marketing version.
Image caption: A compatibility chain showing the device, vendor modules, KMI generation and candidate GKI kernel.
Back up and prepare a recovery route before flashing
Back up photographs, authenticator recovery codes, messages and application data before unlocking or flashing. Bootloader unlocking performs a factory reset on normal Android devices. Backups held only on the phone will be erased with everything else.
Obtain the exact stock factory package for the installed build, not merely a package for the same device model. Extract and retain the original boot, init_boot, vendor_boot and related images where present. Confirm that the computer can detect the phone with both Android Debug Bridge and fastboot before modifying anything.
- Charge the phone and use a reliable data cable.
- Record the device codename, active slot and current build fingerprint.
- Know how to enter the bootloader without Android starting.
- Check whether the manufacturer supplies a complete factory restoration tool.
- Do not relock the bootloader while modified images are installed; verified boot failure can leave the device unable to start.
Unlocking or installing an unofficial kernel may affect warranty support. Kernel replacements can also stop normal OTA installation or be overwritten by an update.
Use this build-selection decision framework
| Check | Accept when | Reject when |
|---|---|---|
| Device | The maintainer names the exact codename or explicitly supports its GKI class | Only a similar model or chipset is mentioned |
| KMI | Linux family, Android kernel branch and required KMI generation match | Only “Android 14”, “Android 15” or “Android 16” matches |
| ROM source | The build supports the installed AOSP or OEM vendor base | An AOSP-only kernel is being guessed onto HyperOS, One UI or another OEM ROM |
| Packaging | The package matches the documented boot, init_boot or installer route | The target partition is inferred from another phone’s guide |
| Root implementation | The embedded KernelSU fork and required manager are identified | The package merely says “KSU” without a project, version or manager source |
| SUSFS | Kernel-side support and any required userspace module version are documented | Only a SUSFS companion module is supplied for an unpatched kernel |
| Maintenance | Source, checksums, changelog and current security fixes are available | The archive is anonymous, abandoned or redistributed without provenance |
A filename is useful evidence, but never decisive evidence. For example, the archived file 6.1.145-android14-2025-08-AnyKernel3.zip identifies Linux 6.1.145, an android14 branch and a dated packaging label. It does not prove compatibility with every device using Linux 6.1.
The archived WildKernels r4 artefact is named 6.1.145-android14-2025-08-AnyKernel3.zip; that filename does not establish Pixel 9 or Android 16 compatibility.
Understand which component provides each capability
KernelSU and its forks
KernelSU handles root in kernel space, with a userspace daemon and manager application controlling access. KernelSU Next, SukiSU Ultra and RKSU share that broad architecture but are not interchangeable binaries. A manager APK does not add KernelSU to a stock kernel, and a Magisk-patched boot image is not a KernelSU kernel.
The correct installation route depends on the device and implementation. Some supported GKI devices can use a project-supplied image or loadable kernel module arrangement. Other devices require a kernel compiled from source. Follow the relevant project’s official KernelSU installation guidance and the device maintainer’s instructions together.
SUSFS
SUSFS is a kernel-side hiding facility, not simply another Magisk-style module. Its companion module or controller exposes configuration to userspace, but cannot create missing kernel support. A package must explicitly state that its kernel contains compatible SUSFS patches or support.
SUSFS can hide selected mounts and filesystem artefacts, yet it is not invisibility. Detection can also use bootloader state, hardware-backed attestation, unexpected processes, SELinux state, build properties or implementation-specific SUSFS signals. Consult the SUSFS project source and documentation for its current capabilities.
A documented Vantom AOSP-only build combined KernelSU Next 1.0.7 build 12646 with SUSFS 1.5.7; those exact versions describe that build, not a universal pairing.
Image caption: KernelSU supplies root management while kernel-side SUSFS and its userspace controller perform separate hiding functions.
How to install a compatible GKI KernelSU SUSFS build
- Back up and unlock deliberately. Export all important data, confirm that restoration works, then follow the manufacturer’s bootloader-unlock procedure. Expect the phone to be wiped. Complete initial setup before continuing.
- Prepare known-good tools and stock images. Install the current official Android SDK Platform-Tools package listed in the appended “Modules, apps & files to try” section. Keep factory images matching the phone’s current build and verify that adb devices and fastboot devices both return its serial number.
- Record the running configuration. Run adb shell uname -r, adb shell cat /proc/version, adb shell getprop ro.product.device, adb shell getprop ro.build.fingerprint and adb shell getprop ro.build.version.security_patch. Save the complete outputs rather than shortening them to “5.15” or “6.1”.
- Confirm the actual KMI. Compare the recorded kernel release with the candidate’s Android kernel branch and Linux family. Check the device support notes for additional KMI-generation, vendor-module or security-patch constraints. Stop if the maintainer does not explicitly cover the combination.
- Confirm the ROM source level. Determine whether the installed ROM uses an AOSP base or an OEM vendor stack. A Vantom build labelled AOSP-only, for example, is not a supported choice for MIUI, HyperOS or another OEM ROM merely because it might boot.
- Identify the exact installation format. Establish whether the package is a complete boot image, an init_boot patch, a loadable implementation or an AnyKernel3 archive. Use the partition and flashing method stated for the device. Never substitute boot for init_boot by guesswork.
- Download the matched components. Obtain the kernel package, the named KernelSU or KernelSU Next manager APK and any specifically required SUSFS companion module from the verified entries in “Modules, apps & files to try”. Record release tags and compare published SHA-256 checksums where available.
- Remove conflicting root modifications. Use the existing root manager’s documented uninstall process before changing architecture. In particular, remove Magisk before installing a kernel whose maintainer requires an unmodified boot environment. Reboot and verify the previous root implementation is gone.
- Test boot where the device supports it. For a maintainer-approved complete boot image, use the documented temporary fastboot boot filename.img route before permanent flashing. This command is not appropriate for every init_boot image or every device. If temporary boot is unsupported, use only the package’s specified installer and ensure stock restoration is ready.
- Flash only the documented target. If the instructions explicitly require a boot image, the command normally takes the form fastboot flash boot filename.img. If they explicitly require init_boot, it normally takes the form fastboot flash init_boot filename.img. Slot-specific devices may require additional handling defined by their maintainer.
- Complete first boot without extra modules. Allow extra time for the first start. Install the matching manager APK and confirm that it reports the expected KernelSU implementation and exact embedded version. Do not immediately install hiding, performance or integrity modules.
- Enable SUSFS only after kernel verification. Confirm the manager or kernel logs report SUSFS support, then install only the companion version recommended for that build. Reboot and verify that the controller communicates with the kernel. If it reports unsupported functionality, remove it instead of forcing configuration.
Verify stability before testing sensitive apps
Use the phone normally for at least one full charge cycle before adding more modifications. Test calls, cameras, Wi-Fi, Bluetooth, biometrics, USB, charging, mobile data and deep sleep. Kernel and vendor-module incompatibility may appear as missing hardware, random reboots, severe battery drain or performance loss rather than an immediate boot failure.
- Confirm the manager shows the intended KernelSU family and version.
- Grant root only to one trusted test application.
- Check that unapproved applications receive no root access.
- Confirm SELinux remains enforcing.
- Review kernel logs for module-load failures and repeated crashes.
- Reboot twice to ensure the result is persistent.
Some users report lower frame rates or greater battery use with particular KernelSU builds. That is a build-and-device problem, not proof that every KernelSU installation behaves the same way.
Avoid the failure modes seen most often
- Matching the ROM version instead of the kernel: “Android 16” does not identify a KMI.
- Matching only the Linux family: two 6.1 kernels can target different Android branches, generations or vendor expectations.
- Using an AOSP kernel on an unsupported OEM ROM: boot success does not establish hardware stability.
- Installing only a SUSFS module: userspace files cannot supply absent kernel-side support.
- Mixing managers: a KernelSU Next kernel should use the manager release named by its maintainer.
- Stacking hiding modules immediately: overlapping mount and Zygote modifications make boot loops and detection failures harder to diagnose.
- Ignoring security maintenance: an old kernel with effective hiding may expose known vulnerabilities fixed by the stock update.
- Taking an OTA blindly: an update can overwrite modified partitions, fail verification or change the KMI.
Image caption: A pre-flash checklist comparing the running KMI, ROM source, package format, checksum and recovery image.
Banking and Play Integrity remain uncertain
Kernel-level hiding may reduce some observable root artefacts, but Android integrity decisions are layered and change over time. An unlocked bootloader, hardware-backed key state, ROM certification, account state and app-specific checks can all affect the result. A configuration that works today may fail after an app, Play services or server-side policy update.
No guide can promise that SUSFS will satisfy a particular bank, wallet or workplace application. Treat access to sensitive apps as a compatibility requirement to test, not as a guaranteed outcome. If reliable banking access matters more than root, remaining stock or using a separate unmodified device is the lower-risk decision.
Readers new to the underlying trade-offs should start with PrivacyPortal’s practical guide to rooting Android safely. Keep the Android unrooting and stock-restoration guide available before changing kernels.
Plan for OTAs and rollback
Before an OTA, read the kernel maintainer’s update notes and compare the new stock kernel’s KMI with the installed build. Restore the exact stock images when required, apply the update, boot it successfully and then reassess compatibility. Do not reuse a patched image from the previous firmware merely because the partition name is unchanged.
If the phone boot-loops, return to the bootloader and restore the exact stock image for the partition you changed. If hardware fails after boot, remove the custom kernel and restore all partitions altered by its installer. A full factory package may be necessary when an AnyKernel installer changed more than one component.
Frequently asked questions
Can I choose a GKI kernel from the Android version shown in Settings?
No. Record the complete output of uname -r and verify the Linux family, Android kernel branch, KMI generation, device support and ROM source. The displayed Android version is not a sufficient compatibility identifier.
Does a SUSFS module add SUSFS to a stock kernel?
No. The kernel must already contain compatible SUSFS support. A companion module provides userspace configuration and communication; it cannot add the missing kernel implementation by itself.
Can I use a Magisk-patched boot image with KernelSU?
No. KernelSU requires its own supported kernel implementation or installation route. Remove conflicting root modifications and start from the exact stock image when the device guide requires it.
Is KernelSU Next always better than standard KernelSU?
No. KernelSU Next may offer useful SUSFS integration, but compatibility varies by device, kernel and ROM. Standard KernelSU or another maintained fork can be more stable on a particular phone. Use the implementation explicitly supported by the relevant kernel maintainer.
Will GKI KernelSU SUSFS make banking apps work?
Not reliably. It may hide some filesystem and mount artefacts, but apps can inspect other signals or rely on remote integrity verdicts. Never assume that a setup defeats a specific bank’s checks.
Can I relock the bootloader after installing a custom kernel?
Usually not safely unless the device and ROM provide a documented custom verified-boot signing process. Relocking with untrusted or mismatched modified images can prevent the phone from booting. Restore and verify complete stock firmware before considering relocking.
