TL;DR: A KernelSU-Next Manager kernel version match does not always mean identical displayed build numbers. Use the Manager shipped for the same official release as the kernel or driver. The Manager must support that driver’s minimum version and, from v3.3.0, its userspace API must match. If uncertain, pair the release assets exactly.
By the PrivacyPortal team
Last updated 24 July 2026
The safest answer is to match KernelSU-Next by official release, not merely by the numbers shown in the Manager. Different build numbers can work when the Manager supports the installed driver and both sides use a compatible userspace API, or UAPI. In practice, however, mixed releases make faults such as unreliable root authorisation, missing controls and module problems harder to diagnose. Beginners should install the Manager supplied or recommended by their kernel maintainer. Experienced users can mix builds only after checking the release notes, minimum driver requirement and UAPI compatibility.
KernelSU-Next Manager kernel version match: what actually needs to match?
KernelSU-Next has two closely related components. The Manager is the Android application used to grant root access, install modules and configure features. The driver runs inside the kernel and provides the underlying root capability. A custom kernel may compile that driver directly into its image, while another installation may use a supported loadable kernel module, or LKM.
The number displayed for the Manager describes the application build. The kernel or driver number describes the KernelSU-Next code embedded in the running kernel. Those values come from separate build processes, so numerical equality is not a universal compatibility rule.
Three checks matter:
- Minimum driver support: the Manager must still support the installed kernel driver.
- UAPI compatibility: from KernelSU-Next v3.3.0, the Manager and kernel must use a compatible userspace API.
- Release pairing: the project or kernel maintainer should identify which Manager belongs with the kernel build.
KernelSU-Next v3.3.0 made userspace API compatibility a required part of Manager-to-kernel communication; identical displayed build numbers alone do not prove compatibility.
Image caption: The KernelSU-Next Manager and kernel driver communicate through a versioned userspace API.
When identical version numbers are recommended
Some KernelSU-Next releases and community-maintained kernels package Manager and driver builds with the same numeric version. For example, guidance may pair Manager 30100 with kernel driver 30100. When that exact pair is published, use it: the matching numbers identify components that were built and tested together.
This is especially important when installing:
- a newly released KernelSU-Next version;
- a custom kernel with maintainer-specific patches;
- a kernel that integrates SUSFS filesystem hiding;
- a continuous-integration, or CI, build produced between official releases;
- a build whose release notes mention an API or compatibility change.
Matching the package does not mean downloading two files that happen to display the same number from unrelated sources. A custom kernel can alter KernelSU-Next, SUSFS or device-specific behaviour without changing every visible identifier. Prefer the Manager linked by that kernel’s maintainer or the corresponding asset from the official KernelSU-Next releases page.
A reported driver build 32522 behaved unreliably with a different Manager, while the prebuilt 32522 Manager restored the expected allowlist behaviour; this is a troubleshooting example, not proof that every build number must be identical.
Compatibility decision table
| Situation | Likely result | Recommended action |
|---|---|---|
| Manager and kernel came from the same official release | Lowest compatibility risk | Use the pair and verify the reported status after reboot |
| Different displayed numbers, but the release notes explicitly confirm support | Potentially compatible | Proceed only with a backup and a known recovery route |
| New Manager with an older driver | May work if the minimum driver and UAPI requirements are satisfied | Check both releases; do not assume newer automatically means compatible |
| Old Manager with a newer driver | Higher risk of missing commands or features | Install the Manager recommended for the newer kernel |
| Official Manager mixed with an unlabelled CI kernel | Unknown | Find the CI commit and maintainer instructions or avoid the combination |
| Manager reports unsupported, not installed or an incompatible UAPI | Not a valid working pair | Stop configuring modules and install the documented matching release |
A useful rule is simple: same release beats same-looking number. If neither the kernel maintainer nor the official release notes document the combination, treat it as untested.
Back up and prepare a recovery route first
Kernel modification can leave a phone unable to boot. Back up photos, authentication recovery codes, messages and app data before changing anything. Keep copies somewhere other than the phone. If the bootloader is still locked, unlocking it normally performs a factory reset and wipes user data; Android documents this behaviour in its bootloader locking and unlocking guidance.
Before flashing, obtain the exact stock boot-related images for the ROM build currently installed. The relevant partition may be boot, init_boot, vendor_boot or another device-specific partition. Do not guess. Verify the device codename, Android build, kernel branch and maintainer instructions.
Rooting can also affect warranty support, over-the-air updates, device encryption assumptions, banking apps, work profiles, streaming services and Play Integrity results. No KernelSU-Next, SUSFS or module configuration can be promised to pass a particular bank’s checks. Detection changes on both the app and operating-system sides.
Readers new to these risks should start with our Android bootloader unlocking guide and practical Android rooting guide before flashing a kernel.
How to install a correctly paired KernelSU-Next Manager and kernel
This procedure is deliberately device-neutral because partition layouts and flashing commands vary. Follow your device maintainer’s documented method whenever it differs. Never flash an image intended for another device, ROM build or kernel branch.
- Back up the phone. Copy important files off-device, export authentication recovery information and confirm that the backup opens. If unlocking is required, complete the backup before starting because bootloader unlocking wipes data.
- Record the exact device state. Note the model, codename, Android version, ROM build number, kernel version and current root method. Take screenshots or write the values somewhere accessible if the phone stops booting.
- Prepare recovery files. Download the factory or ROM package matching the installed build and extract the stock images specified by the device guide. Confirm that Android Platform Tools can detect the phone with adb devices and, in bootloader mode, fastboot devices.
- Choose one documented release pair. Open the kernel maintainer’s release notes and the official KernelSU-Next release information. Select the kernel image and Manager APK identified as compatible with each other. Avoid mixing an official Manager, a nightly kernel and an unrelated SUSFS package merely because their version numbers look similar.
- Check the installation type. Determine whether the release uses an integrated GKI kernel, a device-specific custom kernel or a supported LKM method. GKI means Generic Kernel Image, Android’s standardised kernel architecture. The correct method and partition depend on the device.
- Remove conflicting root implementations if required. Follow the maintainer’s migration instructions before moving from Magisk, APatch, standard KernelSU or another fork. Stacking two root implementations can cause boot loops, duplicate mounts and misleading detection results. Do not casually uninstall the active method until the recovery images are ready.
- Install the kernel using the documented tool. Use the maintainer’s supported recovery, fastboot procedure or kernel flasher. Recheck the destination partition before confirming. Do not reuse a command copied from another model: flashing the wrong partition can prevent booting.
- Boot Android before adding modules. Allow extra time for the first boot. If the phone loops or returns to the bootloader, use the prepared stock image and the device’s documented recovery procedure. Do not repeatedly flash unrelated images in an attempt to make it boot.
- Install the paired KernelSU-Next Manager APK. Use the exact official or maintainer-linked Manager selected in step four. Android may require permission for the browser or file manager to install that APK. Disable that permission again afterwards if it is no longer needed.
- Verify Manager-to-kernel communication. Open KernelSU-Next Manager and confirm that it reports KernelSU-Next as installed, shows a driver or kernel version, and does not display an unsupported-version or UAPI error. Test root with a harmless, trusted application and revoke the grant afterwards.
- Add modules one at a time. Reboot and verify basic operation after every module. Use only packages built for KernelSU-Next or explicitly declared compatible. The automatically appended Modules, apps & files to try section should be treated as a starting point; each file still needs to match the installed kernel and Android build.
- Test normal phone functions. Check calls, Wi-Fi, Bluetooth, camera, biometrics, encryption, charging and any essential apps. Keep the stock images until the phone has survived several reboots and an update plan is clear.
Image caption: Verify the installed driver, Manager release and compatibility status before enabling any root modules.
How to diagnose a Manager and kernel mismatch
A clean Android boot does not prove that KernelSU-Next is correctly paired. The kernel can boot while the Manager fails to control part of the driver interface.
Common mismatch symptoms include:
- the Manager says KernelSU-Next is not installed or unsupported;
- root grants do not persist or the allowlist behaves inconsistently;
- kernel-dependent controls are missing from the Manager;
- modules install but their WebUI or service does not work;
- the Manager reports a UAPI or minimum-driver incompatibility;
- behaviour changes after updating only the APK or only the kernel.
Start with a clean comparison. Disable optional modules, record both displayed versions and identify the source release for each component. Reinstall the Manager supplied with the kernel release. If that fixes the fault, the mixed Manager was the likely cause. If it does not, restore the stock kernel or ask the kernel maintainer with logs and exact build details.
Do not diagnose every banking-app or Play Integrity failure as a version mismatch. Attestation can change because of the bootloader state, ROM certification, security patch level, device-specific key status, modules or server-side app policy.
SUSFS support is a separate compatibility question
SUSFS, short for SUS File System, adds kernel-level filesystem hiding. It works only when the installed kernel has been compiled or patched with compatible SUSFS support. Installing a module cannot add the missing kernel implementation by itself.
If KernelSU-Next Manager or a module WebUI says SusFS not supported, changing to a numerically matching Manager usually will not solve it. Confirm that the kernel release explicitly includes SUSFS and identifies the supported SUSFS and KernelSU-Next versions.
A kernel with SUSFS already integrated may not require a separate SUSFS module. Adding another implementation can create conflicts. Community reports have also identified interactions between some SUSFS and integrity-related module releases, so introduce only one change per reboot.
Image caption: SUSFS requires support inside the running kernel; a Manager APK or standalone module cannot supply that kernel patch.
Updates, OTA installations and rollback planning
An over-the-air Android update can replace the kernel or boot-related partitions, removing KernelSU-Next or creating a new version combination. Before accepting an OTA, obtain the new ROM’s stock images and check whether a compatible KernelSU-Next kernel exists for that exact build.
Do not automatically reuse a kernel built for the previous security patch. Kernel ABI stability helps some GKI configurations, but it does not make every image interchangeable across devices or firmware releases. Device-specific modules, vendor changes and boot image formats still matter.
Keep a small record containing:
- ROM build and security patch date;
- kernel filename, source and checksum;
- KernelSU-Next Manager version and source;
- SUSFS version, if integrated;
- installed modules and the order they were enabled;
- the stock recovery images and restoration procedure.
As of 24 July 2026, PrivacyPortal’s safest recommendation is to pair Manager and driver by their documented KernelSU-Next release, then verify minimum-driver and UAPI compatibility before installing modules.
Frequently asked questions
Do KernelSU-Next Manager and kernel build numbers have to be identical?
No. Different displayed build numbers can be compatible when the Manager supports the driver and their UAPI versions match. Identical numbers are still preferable when the project or kernel maintainer publishes them as a tested pair.
What should I do if the Manager is newer than the kernel?
Check the Manager’s minimum supported driver version and the release notes for UAPI changes. If compatibility is not explicitly documented, install the Manager packaged for the kernel release or update both components as a tested pair.
Can I update only the KernelSU-Next Manager APK?
Sometimes, but an APK update is not automatically safe just because Android installs it successfully. Confirm that the new Manager retains support for the installed driver and UAPI. Keep the previous trusted APK available for rollback.
Will matching versions make banking apps or Google Wallet work?
No guarantee is possible. Correct pairing can fix Manager and driver communication, but financial apps may inspect the bootloader, ROM, attestation results, root artefacts and other signals. A method that works on one device or app version may fail on another.
Does “SusFS not supported” mean the Manager version is wrong?
Usually it means the running kernel lacks compatible SUSFS support. Install only a kernel explicitly built with the required SUSFS implementation for the exact device and firmware. A Manager APK or ordinary module cannot independently add the missing kernel code.
Where should I download KernelSU-Next?
Use the official KernelSU-Next project repository, its release assets, or the exact source linked by a reputable device-kernel maintainer. Avoid renamed APKs, untraceable mirrors and packages without release notes or checksums.
What is the safest choice when compatibility information is unclear?
Do not flash the uncertain combination. Use the Manager and kernel distributed together in one documented release, or remain on the current working setup until the maintainer confirms compatibility. A recoverable, known-good phone is more valuable than a speculative update.
