TL;DR: KernelSU hooks on legacy kernels work with GCC or Clang. Use the compiler and exact build settings that produced your device’s stock kernel. Changing toolchains can alter symbols, function folding and ARM64 branch calls. Official non-GKI support ended at KernelSU v0.9.5, so this is now an archival, self-supported route.
By the PrivacyPortal team
Last updated August 2026
For an older, non-GKI Android kernel, compiler fidelity matters more than compiler preference. Start with the vendor’s known-good toolchain, defconfig and source revision. Use GCC when the stock kernel used GCC. Use Clang when its build scripts require Clang. A successful compile is not enough: compare the result with the stock kernel, test boot before flashing where possible, and verify KernelSU from Android. Back up first. Unlocking the bootloader wipes user data, while a bad image can leave the phone unable to boot.
Image caption: A legacy Android kernel build tree beside its matching compiler and stock boot image.
What KernelSU hooks do on a legacy kernel
KernelSU provides root access from the Linux kernel. Current devices normally use a Generic Kernel Image, or GKI, with supported built-in or loadable module workflows. Older non-GKI devices need changes inside their device-specific kernel source.
Legacy KernelSU integration intercepts selected kernel operations. Depending on the old release and configuration, it may use kprobes or manual hook changes. These let KernelSU recognise authorised root requests and communicate with its userspace daemon.
This is not the normal path for current KernelSU. The old hook code must match the kernel’s functions, types and control flow. Vendor changes can move or rename expected targets even when two devices report the same Linux version.
Official KernelSU support for non-GKI kernels ended at v0.9.5, according to the official KernelSU installation guide.
The kernelsu legacy kernel hooks path should therefore be treated as archived code. It receives none of the assumptions or support offered by the current project.
KernelSU hooks: should you use GCC or Clang?
Use the compiler recorded in the vendor’s build scripts and release notes. If that evidence is incomplete, inspect the Makefile, build configuration and stock kernel version string. Do not choose Clang merely because it is newer.
| Situation | Best starting point | Reason |
|---|---|---|
| Vendor build uses GCC | Matching GCC release and binutils | It preserves the expected ABI, symbols and optimisation behaviour. |
| Vendor build uses Clang | Matching Clang revision and LLVM tools | Android kernel trees may depend on LLVM-specific flags and scripts. |
| Vendor used a mixed toolchain | Reproduce that complete toolchain | Some trees use Clang to compile but GNU tools for linking or assembly. |
| Original toolchain is unknown | Rebuild without KernelSU first | A clean baseline separates toolchain faults from hook faults. |
| Supported modern GKI device | Current official KernelSU workflow | Legacy source hooks add avoidable work and security debt. |
A reproducible stock-style build is the decision gate. If the untouched source cannot make a booting image, adding root code will only hide the real fault.
How compiler optimisation changes old hooks
GCC function folding can remove an expected target
The phrase kernelsu gcc function folding describes a real class of build failure. GCC can merge equivalent functions, create aliases or replace a normal call with another control-flow form. Interprocedural optimisation makes this more likely.
A hook patch may expect a separate function body or an ARM64 branch-and-link instruction. If GCC folds that function, the build may still succeed. The hook scanner can then fail at boot because its expected target no longer exists in that form.
Do not disable random optimisation flags across the whole kernel. First reproduce the vendor flags. Then compare symbols and disassembly around the failed target. Make the smallest source-level change needed for that specific tree.
A Clang build can change the same call path
A kernelsu clang kernel build is not immune to optimisation changes. Clang may inline a function, emit a tail call or arrange sections differently. Link-time optimisation, known as LTO, can change the final image further.
Moving a GCC-era kernel to modern Clang also exposes unrelated warnings and assembly errors. Those errors do not prove that KernelSU needs GCC. They usually show that the old tree was never maintained for that Clang revision.
The safest test is simple: build and boot the unmodified kernel with the proposed compiler. Only integrate archived KernelSU code after that baseline works.
What a KernelSU branch link failure means
On ARM64, a branch-and-link instruction calls a function while retaining a return address. Some KernelSU hook implementations inspect or alter this call path. Compiler output and vendor patches can prevent the expected instruction from being found.
A kernelsu branch link failure therefore points to a mismatch in generated machine code. It does not automatically mean that the compiler is broken. Inspect the exact call site in the final linked image, not only the C source.
The referenced KernelSU implementation can fall back to syscall-table hooking when ARM64 branch-link patching fails. That fallback changes the interception route and should not be assumed to work on every vendor kernel.
The ARM64 implementation documents a syscall-table fallback after branch-link hook failure in the archived KernelSU hook source.
Image caption: ARM64 control flow showing a direct branch-link hook and the syscall-table fallback.
How to install legacy KernelSU hooks safely
This process is for your own device and assumes you can build its complete kernel source.
- Back up photos, app data, recovery codes and the original boot image. Confirm that the backup can be opened elsewhere.
- Unlock the bootloader using the device maker’s documented process. This wipes the phone and may affect warranty or support.
- Record the exact firmware build, kernel version and Android security patch level. Obtain the matching source, defconfig and stock boot image.
- Recreate the vendor toolchain. Build the untouched kernel first and resolve every error before adding KernelSU.
- Check out the archived official KernelSU v0.9.5 source. Do not mix its kernel code with a random current manager or fork.
- Integrate the old kernel directory and enable its required configuration. Apply only the manual hook changes required by that archived revision.
- Build with the stock compiler flags. Keep the full log, final configuration, symbol map and unstripped kernel image.
- Repack the kernel into a copy of the matching stock boot image. Preserve its header version, ramdisk, command line and partition layout.
- Test the image with a temporary boot command if the device supports one. Otherwise ensure that the stock image can be restored before flashing.
- Boot Android, install the matching KernelSU Manager, and verify root only with a low-risk test app. Do not grant access to unknown apps.
Prerequisites and real files
You need an unlocked device, matching kernel source, the vendor defconfig, the original boot image and enough disk space for a full build. You also need the exact GCC, Clang, binutils and build scripts used by that source.
Use the archived KernelSU v0.9.5 kernel source and a compatible KernelSU Manager build. The “Modules, apps & files to try” section provides the named downloads selected for this guide. Check package signatures and release provenance before use.
Read Android’s official kernel build documentation for its current build concepts. Vendor trees can still require older commands.
Verification before daily use
First confirm that Android reports the expected kernel and firmware. Open KernelSU Manager and check whether it recognises the embedded KernelSU version. A manager screen alone does not prove that every hook works.
- Review the kernel log for hook, symbol, SELinux and daemon errors.
- Reboot at least twice and test charging, Wi-Fi, cameras and mobile data.
- Confirm that unapproved apps receive no root access.
- Keep the stock boot image and recovery procedure on another computer.
- Check over-the-air update behaviour before accepting an update.
Banking, wallet and streaming apps may reject any unlocked or modified phone. No KernelSU setup can guarantee that a specific app will pass Play Integrity or its own checks.
Common failure patterns and practical fixes
| Symptom | Likely cause | Useful next check |
|---|---|---|
| Untouched kernel will not boot | Wrong source, defconfig or toolchain | Match the stock build before adding hooks. |
| Hook target is missing | Inlining, folding or vendor refactoring | Inspect symbols and final ARM64 disassembly. |
| Branch-link search fails | The expected call instruction changed | Compare compiler flags, LTO and the call site. |
| Kernel boots but Manager says unsupported | Kernel and Manager versions do not match | Use a compatible archived pair from trusted releases. |
| Boot loop after repacking | Wrong boot header, ramdisk or partition image | Restore stock and review the pack command. |
| Root works but core features fail | SELinux, module or vendor-driver conflict | Remove modules and test the clean rooted kernel. |
Change one variable per build. A new compiler, new KernelSU revision and new boot packer in one test make the result hard to diagnose.
Security, updates and recovery risks
Archived root code carries more risk than a supported kernel path. Kernel-level flaws can expose the whole device. KernelSU v0.9.5 also predates later project fixes and current Android releases.
KernelSU v3.2.5 was released on 23 June 2026; it targets the current GKI and LKM era rather than restoring official legacy-hook support.
An unlocked bootloader weakens physical protection and shows a boot warning. Root can also expand the damage caused by a malicious app. Grant access sparingly and keep USB debugging off when it is not needed.
Firmware updates may overwrite the rooted boot partition or change the kernel ABI. Never reuse an old patched image after an OTA update. Extract and test the image from the new firmware.
If you are new to these risks, read our bootloader unlocking guide and private Android backup guide before modifying the phone.
Image caption: A recovery checklist with stock firmware, boot image and verified backups stored off-device.
When a legacy build is the wrong choice
Stop if the vendor has not released matching kernel source, the stock build cannot be reproduced, or no reliable recovery path exists. A successful compilation does not justify flashing an unverified image.
A current GKI-compatible device should use a maintained KernelSU workflow instead of kernelsu hooks. A supported custom kernel may also be safer than reviving abandoned integration code. Check that it matches the exact device model and firmware.
For readers who want privacy without root maintenance, a supported de-Googled device is often the calmer choice. PrivacyPortal’s privacy-first Android phones provide that route without asking users to maintain an archived kernel fork.
Frequently asked questions
Does KernelSU require Clang?
No. Legacy KernelSU can be built with GCC or Clang when the device kernel supports that compiler. The correct choice is the toolchain used by the known-good vendor build.
Why does GCC build the kernel but break the hook?
GCC may inline, fold or redirect an expected function under different flags. The image can compile and boot while a runtime hook cannot find its intended ARM64 call site.
Can I use current KernelSU with a non-GKI kernel?
Current official KernelSU does not support the old non-GKI integration route. Official support ended at v0.9.5. Forks may differ, but their claims and device support need separate review.
Will legacy KernelSU make banking apps work?
There is no reliable promise. Apps can inspect bootloader state, Play Integrity results and their own signals. Detection changes without notice, and different banks use different checks.
Can I flash a KernelSU-patched image made for another ROM?
No. Even the same phone model may use a different kernel, ramdisk or boot header after an update. Use source and images matching the exact installed firmware.
Is a temporary boot test completely safe?
No. It reduces the need to overwrite the boot partition, but a bad kernel can still crash or corrupt data. Some devices do not support temporary booting at all. Keep a tested stock recovery route.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
