How to Build KernelSU Next and SuSFS Kernel Changes From Source

TL;DR: To build SuSFS for KernelSU from source, first reproduce the stock kernel, pin compatible KernelSU Next and SuSFS revisions, apply a reviewed KernelSU-Next compatibility patch, enable the required configuration, compile with the vendor-supported toolchain, repack without changing boot metadata, and test by temporarily booting the image where supported.

By the PrivacyPortal team

Last updated July 2026

Building KernelSU Next with SuSFS is a device-specific kernel engineering task, not a universal patch-and-flash recipe. KernelSU Next v3.3.0 supports documented Android kernel branches from 4.4 through 6.6, while official SuSFS patches vary by kernel branch and are primarily based on original KernelSU. A reliable build therefore requires the exact device source, matching configuration and Kernel Module Interface (KMI), pinned revisions, and a verified compatibility patch. Back up everything first: unlocking the bootloader wipes user data, and an incompatible image can prevent the phone from booting.

A source tree, pinned revisions and the original boot image form the foundation of a reproducible KernelSU Next and SuSFS build.

How to build SuSFS for KernelSU from source safely

The safest workflow has three gates. First, compile an unmodified kernel that boots. Second, integrate KernelSU Next and confirm root works without SuSFS. Third, add the matching SuSFS changes and retest. If a stage fails, stop there; combining every patch before the baseline works makes failures unnecessarily difficult to diagnose.

SuSFS adds kernel-level facilities used to alter what selected userspace processes can observe. A flashable userspace module cannot create those facilities on its own. The kernel must contain the matching hooks, configuration and exported interface expected by the module.

KernelSU Next v3.3.0 was the latest official release on 19 July 2026, with published kernel compatibility covering Linux 4.4 through 6.6.

Linux 6.12 is outside that published compatibility statement. A community patch or successful build is not equivalent to official support, so treat 6.12 work as development and review every ported change.

Prerequisites and risks

Back up photos, authentication seeds, app data and any encryption keys before unlocking or flashing. Keep a complete stock firmware package and a known-working copy of boot.img, init_boot.img, vendor_boot.img, dtbo.img and vbmeta.img where applicable. Do not assume that a generic image from another regional or monthly build is recoverable on your device.

• Unlocked bootloader: unlocking normally performs a factory reset and may affect warranty or support arrangements.
• Exact kernel source: use the source corresponding to the installed firmware build, including vendor modules and device-specific changes.
• Linux build host: use the environment documented by the source maintainer. Windows users should prefer a Linux machine or virtual machine; files stored on an NTFS-mounted WSL path can cause case-sensitivity and permission problems.
• Supported toolchain: use the exact Clang and build tools named by the branch manifest or build configuration, rather than substituting the newest compiler.
• Android platform tools: use current official adb and fastboot tools, with a reliable cable and sufficient battery charge.
• Recovery route: verify that fastboot, fastbootd or the manufacturer’s recovery utility can restore the original partitions.

Rooting weakens Android’s standard security model. Bootloader state and kernel modifications can affect over-the-air updates, Widevine level, corporate management, Play Integrity and banking or payment apps. No KernelSU, SuSFS or module combination can be promised to pass a particular app’s checks.

Choose the correct build path

GKI means Generic Kernel Image, Android’s effort to separate a common kernel from hardware-specific vendor modules. GKI does not make kernels interchangeable: the Android release, kernel branch, KMI generation, security patch level and boot-image layout must still match.

The correct branch is selected from the phone’s firmware and KMI, not merely from its model name or Linux version.

Numbered build and installation procedure

1. Record the running device state. Save the full firmware build number, Android version and security patch date. Run adb shell uname -a, adb shell cat /proc/version and, where available, adb shell getprop ro.kernel.version. Preserve the output with the stock images.
2. Obtain the matching source and build instructions. Start from the manufacturer’s release tag or the correct Android common-kernel manifest. Follow the relevant official Android kernel build documentation. Fetch submodules and vendor repositories required by that exact branch.
3. Pin and record every revision. Check out immutable tags or commit hashes for the kernel, toolchain, KernelSU Next, SuSFS and the compatibility patch. Record each hash with git rev-parse HEAD. Do not build from moving branch heads if you want a result that can be reproduced later.
4. Build an untouched baseline. Use the source tree’s documented build command, such as its Kleaf/Bazel target, build/build.sh configuration or vendor build script. Do not guess between them. Confirm the compiler version printed in the log matches the branch configuration. A baseline that does not compile and boot must be fixed before root changes are added.
5. Compare baseline artefacts. Inspect the generated Image, modules and distribution directory. Check that required vendor modules load and that the output uses the expected compression. Repack a test boot image with the original header version, command line, page size, ramdisk, DTB and partition assumptions intact.
6. Integrate KernelSU Next v3.3.0. Follow the integration method documented in the pinned KernelSU Next source. Review the resulting Git diff before compiling. For older, non-GKI kernels, expect branch-specific changes rather than assuming the current GKI integration applies unchanged.
7. Build and test KernelSU Next alone. Compile a second image and, if the device supports non-destructive booting, use fastboot boot instead of flashing. Not every phone supports that command. Confirm Android starts, networking and storage work, and the matching KernelSU Next Manager recognises the kernel. The manager APK alone cannot install kernel support.
8. Select the matching SuSFS branch. Obtain SuSFS from Simonpunk’s official SuSFS repository. Match the patch to the Android kernel branch, not simply the newest SuSFS release number. Read rejected hunks rather than forcing them into files with similar names.
9. Apply a verified KernelSU-Next compatibility patch. Official SuSFS changes are principally structured around original KernelSU. Use a compatibility patch explicitly written for the pinned KernelSU Next and SuSFS revisions. Inspect it for changes to credentials, mount handling, VFS hooks, symbol exports and userspace interfaces. A patch advertised only as “latest” is not a reproducible dependency.
10. Enable the required configuration. Apply the documented KernelSU Next and SuSFS Kconfig symbols through the device defconfig or configuration fragment. Run the branch’s normal configuration regeneration step, commonly make O=out olddefconfig, then inspect the final out/.config. A symbol requested in defconfig can silently become disabled when a dependency is missing.
11. Rebuild from a clean output directory. Save the complete log and verify that no patch hunk, warning promoted to an error, duplicate symbol or undefined reference was overlooked. Run git diff --check and archive the source hashes, final configuration and artefact checksums.
12. Repack with stock metadata. Replace only the component required by the device’s boot layout. KernelSU requires a kernel containing its code; a Magisk-patched boot image is not a substitute. Do not blindly flash boot.img when the device’s kernel or ramdisk belongs in another partition.
13. Boot-test before permanent installation. Use temporary fastboot boot where genuinely supported. Otherwise ensure the exact restore command and stock image are ready before flashing. Confirm display, touch, radio, Wi-Fi, Bluetooth, camera, storage, encryption and sleep behaviour—not just successful entry to the launcher.
14. Install matching userspace files. Install the KernelSU Next Manager and the SuSFS userspace module identified in the appended “Modules, apps & files to try” section. Versions must match the kernel-side interface. Reboot and check the manager and module logs for unsupported-feature or API-mismatch messages.
15. Verify and retain a rollback package. Confirm the reported kernel build string, KernelSU status and SuSFS feature status. Run adb shell dmesg where permitted and capture relevant logs immediately after boot. Restore the stock image if hardware, encryption, updates or important apps behave unexpectedly.

A SuSFS userspace module cannot add missing kernel hooks; the running kernel must already contain a compatible SuSFS implementation.

What to verify after the first boot

A booting launcher proves only that early boot completed. In practice, KMI mismatches can surface later as broken Wi-Fi, cameras, charging, suspend or vendor modules. Test one variable at a time and keep the KernelSU Next allow-list empty except for a trusted diagnostic shell during initial validation.

• The displayed kernel build matches the artefact you compiled.
• KernelSU Next Manager reports a supported kernel-side version without API errors.
• The SuSFS module reports its expected kernel features rather than merely showing “installed”.
• All vendor modules load without unknown-symbol or signature errors.
• File-based encryption, lock-screen credentials and recovery still work.
• Two complete reboot cycles succeed, including a cold boot.
• OTA behaviour is understood before accepting an update that may replace the modified partition.

For broader preparation and recovery context, read PrivacyPortal’s guide to unlocking an Android bootloader safely and Android backup checklist before rooting.

Common build failures and what they mean

Patch hunks fail or land with offsets

The SuSFS patch probably targets a different Android kernel branch or security-patch state. Do not use reject-ignoring options. Compare the affected functions with the intended upstream version and port the semantic change only if you can review it safely.

The configuration says SuSFS is disabled

A Kconfig dependency may be missing, or the build may regenerate configuration from another fragment. Inspect the final out/.config after the build system has processed every fragment. Editing an intermediate configuration file is often overwritten.

The phone loops at the boot logo

Restore the exact stock image using the previously verified recovery path. Common causes include the wrong KMI, boot-header changes, incompatible vendor modules, an incorrect DTB or flashing the wrong partition. Logs from pstore or ramoops can help if the device exposes them after recovery.

The manager cannot see KernelSU

The device may still be running the stock kernel, the kernel integration may be absent, or the manager and kernel APIs may not match. Confirm the running build string and hashes before reinstalling applications.

Important apps stop working

Root, an unlocked bootloader or altered integrity signals may be detected independently of SuSFS. Restore stock if access to an essential banking, identity or workplace app matters more than root. PrivacyPortal does not recommend weakening app security or relying on a configuration to defeat a specific service’s checks.

Successful validation includes hardware, encryption, logs and rollback—not merely reaching the Android home screen.

Frequently asked questions

Can I build SuSFS for KernelSU Next with one universal script?

No. Kernel branches, source layouts, KMI requirements and boot-image formats differ. Automated scripts can fetch or apply known patches, but they cannot establish that those changes match a particular device and firmware release.

Does KernelSU Next v3.3.0 support Linux 6.12?

Official published compatibility as of 19 July 2026 covers kernel versions 4.4 through 6.6. A 6.12 community port should be treated as experimental until the project documents support for it.

Can I install the SuSFS module without rebuilding my kernel?

Only if the running kernel already includes compatible SuSFS support. Installing a userspace module cannot create missing kernel hooks.

Should I use boot.img or init_boot.img?

That depends on the device’s boot architecture. KernelSU requires a patched kernel, while init_boot commonly contains a generic ramdisk rather than the kernel itself. Inspect the stock firmware and follow device-specific documentation instead of assuming a partition name.

Will KernelSU Next and SuSFS make banking apps work?

There is no guarantee. Apps can consider bootloader state, Play Integrity, kernel changes, installed software and their own server-side risk signals. Detection also changes without notice.

Can I return to stock?

Usually, if the bootloader remains usable and you retained exact stock images for the installed firmware. Restoring a kernel partition does not necessarily relock the bootloader or reverse every state change. Never relock until the phone is completely stock and verified boot succeeds.