TL;DR: KernelSU Next SUSFS compatibility depends on the exact kernel currently running. A KernelSU Next manager APK or SUSFS userspace module cannot add missing kernel support. Back up first, verify KernelSU Next reports a working kernel integration, then confirm the SUSFS WebUI recognises the kernel before configuring any hiding rules.
By the PrivacyPortal team
Last updated July 2026
To verify KernelSU Next and SUSFS support reliably, check the running kernel rather than relying on the phone model, Android version or downloaded APKs. A compatible setup needs KernelSU Next integrated into the kernel and the required SUSFS patches compiled into that same kernel. If either runtime check fails, installing more modules will not create compatibility.
KernelSU Next SUSFS compatibility explained
KernelSU Next, often shortened to KSUNext or KSUN, provides root access from the Android kernel. SUSFS, meaning SUS File System, adds kernel-level mechanisms that can conceal selected files, mounts and other modification indicators from applications.
The KernelSU Next manager is only the control interface. Similarly, a SUSFS4KSU module supplies userspace tools and configuration; it does not patch the running kernel. Successful installation of either file therefore proves very little by itself.
A device is compatible only when all of the following are true:
- The currently booted kernel contains a compatible KernelSU Next integration.
- That kernel was built with the corresponding SUSFS patches and configuration.
- The installed manager and SUSFS userspace components can communicate with those kernel features.
- The kernel matches the device, ROM build, Android boot layout and security patch level for which it was produced.
Android version and kernel version can narrow the search, but neither guarantees support. Two phones with the same model name may run different regional firmware, boot image formats or custom-kernel revisions.
PrivacyPortal’s compatibility rule as of 20 July 2026 is simple: confirm both KernelSU Next and SUSFS at runtime before calling a device compatible.
Back up before unlocking or flashing
Back up photographs, authenticator recovery codes, messages, app data and any files that exist only on the phone. Copy the original boot-related images for the installed firmware build where possible. A backup stored on the phone will not help after a factory reset or failed boot.
Unlocking the bootloader normally wipes user data. It can also affect warranty support, over-the-air updates, device encryption behaviour and access to applications that inspect boot state. Flashing an image to the wrong partition can leave the phone unable to boot; recovery may require factory firmware and another computer.
Root access also weakens Android’s security boundaries. A malicious or carelessly approved root application can alter protected data across the device. Use a screen lock, grant root only to software you trust and keep the manager’s superuser list small.
Banking, workplace, streaming and contactless-payment applications may use Play Integrity, hardware-backed key attestation or their own detection systems. SUSFS can reduce some visible modification signals, but it cannot guarantee that a particular application will work. Detection changes on both the Android and application sides.
Image caption: A safe preparation checklist showing an off-device backup, matching factory images and a charged phone before bootloader work begins.
Compatibility decision table
| What you observe | What it proves | Decision |
|---|---|---|
| Manager says KernelSU Next is working and SUSFS WebUI reports support | Both components are available in the running kernel | Compatible for controlled testing |
| Manager works, but WebUI says “SusFS not supported” | KernelSU Next is present; required SUSFS support is absent or incompatible | Use a correctly patched kernel |
| Manager says KernelSU is not installed | The running kernel does not expose a compatible KernelSU Next interface | Do not install SUSFS modules yet |
| A SUSFS4KSU module installs successfully | Only the module files were accepted | Runtime verification is still required |
| A device group says the model is supported | At least one build may have worked | Match the exact ROM and kernel build |
| An application passes Play Integrity checks | That application accepted the present state at that time | Not proof of kernel compatibility or future app access |
Identify the running kernel and device build
Record the evidence before downloading anything. In Android settings, note the exact model, build number, Android version and security patch level. From Android Debug Bridge, or ADB, the following commands provide a useful baseline:
- adb shell uname -r reports the running kernel release.
- adb shell uname -a adds architecture and build information.
- adb shell getprop ro.build.fingerprint reports the installed ROM fingerprint.
- adb shell getprop ro.product.device reports the device codename used by many kernel maintainers.
Save this output with the kernel download and its checksum. The Android settings page may show a friendly kernel label that omits important build details, while a file name such as “Android16-KSUN-SUSFS” remains too vague to establish compatibility.
General Kernel Image, or GKI, devices share a standardised Android kernel interface, making supported kernel replacement and integration more practical. GKI is not a promise that an arbitrary generic image will boot. Vendor modules, kernel module interfaces and boot-header details still have to match.
Android’s official Generic Kernel Image documentation identifies Android 12 with kernel 5.10 as the launch point for GKI 2.0.
Non-GKI devices generally require a device-specific kernel compiled from source with KernelSU Next and SUSFS patches. There is no safe universal image for that case.
How to install and verify KernelSU Next with SUSFS
This procedure assumes you are modifying your own device and have found a kernel explicitly built for its exact codename, ROM family and firmware release. Consult the official KernelSU Next project and the kernel maintainer’s instructions before flashing. The relevant manager and userspace files are identified in the appended “Modules, apps & files to try” section.
- Make an off-device backup. Export important data and authentication recovery material. Obtain the matching factory firmware and confirm that you know how to reach the bootloader or recovery mode.
- Record the stock state. Save the device codename, ROM build fingerprint, security patch level and output from adb shell uname -a. Preserve original boot, init_boot and vendor_boot images when the factory package provides them.
- Confirm the bootloader consequences. If unlocking is required, expect a factory reset. Follow the device maker’s documented process and complete the wipe before restoring sensitive data. Some manufacturers do not provide an official unlock route.
- Select an exact kernel build. Its release notes should explicitly name KernelSU Next and SUSFS support, plus the supported device, ROM type and firmware base. Do not treat “KernelSU compatible” as proof of SUSFS support.
- Verify the download. Compare its cryptographic checksum with the maintainer’s published value. Confirm that the archive has not been repackaged by an unrelated mirror.
- Install the KernelSU Next manager APK. Use the manager release required by the kernel maintainer. Opening the app before flashing provides a useful baseline: it should not falsely turn an unsupported stock kernel into a working installation.
- Flash using the maintainer’s exact method. Some builds replace boot, others use init_boot, a recovery installer or another device-specific route. Never guess the partition. Commands such as fastboot flash boot boot.img and fastboot flash init_boot init_boot.img are not interchangeable.
- Boot once without extra modules. Confirm that Android starts, mobile data, Wi-Fi, cameras and storage work. If the device bootloops, restore the matching stock image rather than repeatedly flashing unrelated modules.
- Verify KernelSU Next at runtime. Open the manager and confirm that it reports a working KernelSU Next installation and kernel version. Merely seeing the manager’s home screen is not a pass.
- Install the correct SUSFS userspace component if required. Use the SUSFS4KSU module specified by the kernel maintainer, then reboot. A kernel that already bundles the necessary userspace integration may have different instructions.
- Open the SUSFS module WebUI. Confirm that it detects supported SUSFS kernel functionality. A message such as “SusFS not supported” is a definitive failure for the present kernel, even if the module installation screen was green.
- Verify independently. Re-run adb shell uname -a, save screenshots of both status pages and test normal phone functions before adding integrity or Zygisk-related modules. Change one component at a time so a regression can be traced.
Image caption: KernelSU Next manager and SUSFS WebUI status screens providing separate runtime checks for the same running kernel.
What the version numbers do and do not tell you
KernelSU Next and SUSFS versions must be considered as a pair inside a particular kernel build. A higher number is not automatically a better match for an older device or ROM.
For example, one community-documented Vantom AOSP kernel combined KernelSU Next 1.0.7 build 12646 with SUSFS 1.5.7. That pairing demonstrates compatibility only for the stated Vantom build and supported AOSP base. It does not establish that either component will work with another Vantom revision, HyperOS, MIUI or a different device.
A kernel combining KernelSU Next 1.0.7 build 12646 and SUSFS 1.5.7 proves one tested integration, not universal compatibility between those version numbers.
Read the release notes for both the kernel and the official SUSFS4KSU implementation. Look for patch revisions, supported KernelSU branches, kernel-source requirements and known conflicts. Keep the manager version the maintainer tested until the kernel is known to boot and expose SUSFS correctly.
Common failure modes in practice
The manager is installed but says KernelSU is unavailable
An APK cannot inject KernelSU Next into a running stock kernel. Install a compatible prebuilt kernel or compile one from the correct device source. Non-GKI phones normally need the latter.
SUSFS4KSU installs but reports no support
The userspace module has no compatible kernel interface to control. Reinstalling it, changing its permissions or adding a root-hiding module will not supply the missing patches.
The phone bootloops after flashing
Likely causes include the wrong firmware base, incompatible vendor modules, incorrect boot-header handling or flashing the wrong partition. Restore the original image for the installed build. Do not wipe data until recovery options and logs have been assessed.
Root works but an application still refuses to run
Kernel compatibility and application acceptance are separate questions. The application may inspect bootloader state, hardware-backed attestation, installed packages or its own risk signals. No KernelSU Next, SUSFS or integrity-module combination can be promised to satisfy a specific bank.
Over-the-air updates stop working
A modified boot-related image can prevent incremental OTA installation or be overwritten by an update. Preserve stock images and assume every firmware update may require a new, matching kernel build. Never reuse an old patched image after a major firmware change without confirmation.
Readers new to these concepts may want PrivacyPortal’s Android bootloader unlocking guide and guide to Android rooting risks before flashing.
Image caption: A diagnostic flow from manager failure, SUSFS failure or bootloop to the appropriate stock-kernel recovery action.
A reliable go or no-go framework
Proceed only when the evidence chain is complete:
- Identity: the kernel release matches the device codename, ROM and current firmware.
- Provenance: the image comes from its recognised maintainer with a verifiable checksum and source or release notes.
- KernelSU result: the manager reports a working KernelSU Next kernel integration.
- SUSFS result: the module WebUI recognises SUSFS support after reboot.
- Recovery: matching stock images and a tested recovery route are available.
Stop if any item is missing. A device-group recommendation, successful module installation or app-integrity result cannot replace this evidence. PrivacyPortal’s privacy-first Android phones are a more suitable route for people who want greater privacy without maintaining an experimental root stack themselves.
Frequently asked questions
Does installing the KernelSU Next manager add SUSFS support?
No. The manager controls functionality already present in the running kernel. SUSFS support must be compiled or patched into that kernel.
Can I use SUSFS with a stock kernel?
Not unless that exact stock-derived kernel has been rebuilt or patched with compatible SUSFS support. A userspace module alone cannot modify the required kernel code.
Does every GKI phone support KernelSU Next and SUSFS?
No. GKI makes kernel integration more standardised, but the image must still match the device’s Android generation, kernel interfaces, boot format and vendor requirements.
Do I need Shamiko with KernelSU Next and SUSFS?
SUSFS performs kernel-level hiding and does not inherently require Shamiko. Additional modules can introduce conflicts or new detection surfaces, so establish a clean KernelSU Next and SUSFS baseline first.
Will KernelSU Next with SUSFS make banking apps work?
There is no guarantee. Banking apps use changing checks that may include Play Integrity, bootloader state, hardware-backed signals and app-specific detection. A setup that works today may fail after an app, firmware or server-side update.
How do I know whether SUSFS is really active?
Confirm that KernelSU Next reports a working kernel integration, reboot after installing the required SUSFS userspace component, and check that its WebUI detects supported SUSFS kernel functionality. Module installation success alone is insufficient.
Can I keep using the same patched kernel after an OTA update?
Do not assume so. An OTA may replace boot images or change the kernel and vendor interfaces. Obtain a build made for the new firmware, preserve the new stock images and repeat both runtime checks.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
