WildKernels GKI_KernelSU_SUSFS for Generic Android Kernels

What WildKernels GKI_KernelSU_SUSFS Changes

WildKernels GKI_KernelSU_SUSFS addresses Android users who want to build a kernel from Google's Generic Kernel Image source family and add kernel-level root management. Its stated target is GKI 2.0 devices running Linux 5.10 or newer. The project is intended for Android enthusiasts and kernel builders who understand boot images, recovery procedures, and the consequences of replacing kernel code.

The repository groups several functional changes into one build. Its root options are KernelSU, KernelSU-Next, and ReSukiSU. It also includes susfs4ksu for root hiding, with a Ptrace Leak Fix and Unicode Fix named in the feature list. NoMount and Mountify are described as mount metamodules, while Baseband Guard is intended to protect partitions. These are kernel-level choices, not cosmetic settings.

Networking and systems additions include WireGuard, BBR, IPSet, CIFS, TMPFS support for extended attributes and POSIX ACLs, BPF features such as BTF, eBPF, and FUSE-BPF, NTSync, and the DroidSpaces container runtime. The selection is broad enough that feature interaction becomes an engineering concern. Someone who needs one capability should first check whether a module or stock device configuration offers a narrower change.

The README describes the kernels as generic and built for broad compatibility, but it explicitly says compatibility is not guaranteed for every device. A GKI kernel may still depend on device-specific boot configuration, vendor modules, kernel versions, and installation procedures. The README does not provide a per-device compatibility table.

How the GKI Build Configuration Works

According to the README, the kernels are based on Google's GKI sources. The documented build path begins by forking the repository and following `docs/build-from-fork.md`. GitHub Actions is the intended automation environment. The guide lets a builder select a kernel family, patch level, root implementation, and feature set.

This is a source-build project, not an application distributed through a documented package index. The build configuration has several layers. Kernel family and patch level determine the base platform. The root implementation changes which of KernelSU, KernelSU-Next, or ReSukiSU is incorporated. Other groups cover hiding, mounting, partition protection, networking, filesystem behavior, BPF, synchronization, and containers.

The repository layout supports this model. Its top level includes `.github/`, `docs/`, `README.md`, `LICENSE`, and `THIRD_PARTY_NOTICES.md`. The README links build instructions to `docs/build-from-fork.md`, while detailed installation is delegated to the repository Wiki. It does not state an exact local build command, action input, toolchain version, or artifact name, so those details cannot be inferred from unrelated Android kernel projects.

Recent release names include `bazel-cache-android14-6.1-BakaSU (General Cache)`, `r21 (Release 21)`, and `nightly (Nightly (main 2026-10-05))`. These labels show several build or release streams. The README does not map them to individual devices or explain a compatibility and upgrade policy. A user must correlate a release with its build settings and the device's requirements.

Selecting KernelSU, SUSFS, and Mount Changes

The first configuration decision is the root implementation. The README presents KernelSU, KernelSU-Next, and ReSukiSU as alternatives rather than identifying one mandatory default. They are separate implementations credited by the repository. Their behavior, device support, and build requirements should be investigated through their upstream documentation before one is selected.

SUSFS is a separate concern. The project describes `susfs4ksu` as providing root hiding and detection evasion, including a Ptrace Leak Fix and Unicode Fix. The README does not explain which applications are hidden, which detection checks are affected, or whether every root implementation works with every selected SUSFS fork. The feature list is therefore not evidence of a universal guarantee.

Mounting receives similar treatment. NoMount and Mountify are categorized as mount metamodules, but the README does not describe their configuration, activation order, or rollback behavior. Their inclusion does not prove that a device will preserve its expected mount layout after flashing. An experienced builder should identify the original mount configuration and retain an unmodified boot image before applying a custom build.

Baseband Guard is described as partition protection. The README does not present it as a modem backup or recovery system, nor does it explain emergency restoration or behavior on different partition layouts. Users who depend on cellular service should investigate this feature independently before building it into a daily-use image.

Building a Custom Kernel Through GitHub Actions

The README gives a build path at the workflow level but does not print the underlying action inputs or local commands. The confirmed first step is to fork `WildKernels/GKI_KernelSU_SUSFS`. From that fork, open `docs/build-from-fork.md` and use the selections described there.

A short outline based on the README and its linked build guide is:

1. Fork the repository into an account you control. 2. Follow `docs/build-from-fork.md` through the GitHub Actions build flow. 3. Select one supported kernel family and patch level. 4. Select one root implementation and the additional feature groups required by the device. 5. Retain the workflow configuration associated with the resulting build.

No command block is included because the README does not state an exact clone command, action input name, runner selection, or artifact name. A command copied from another GKI kernel repository could use a different toolchain or workflow structure. The linked build document and visible workflow files in the fork are the proper sources for those details.

Before flashing, confirm that the artifact corresponds to the intended device, kernel family, patch level, root implementation, and feature set. The README warns that flashing can result in a bricked device and instructs users to back up their data and understand the risk. Detailed installation instructions are placed in the repository Wiki rather than in the README.

Generic GKI Compatibility and Failure Cases

The central limitation is explicit: broad GKI compatibility does not mean support for every Android device. GKI 2.0 and Linux 5.10+ describe the intended kernel baseline, but the README provides no compatibility table, boot-partition instructions, or per-device flashing procedure. It also does not document rollback. A device can satisfy the broad kernel description and still require handling that the repository has not documented.

Configuration breadth creates another failure mode. BBR changes network behavior, WireGuard introduces a networking facility, CIFS affects filesystem access, BPF options affect related kernel paths, and DroidSpaces changes container behavior. The README does not publish a matrix showing which combinations were built together for each release. A completed workflow does not by itself establish runtime compatibility.

This project is the wrong tool for someone seeking a stock-like OTA experience, an official Pixel or Samsung package, or a vendor-supported flashing path. The README points to separate repositories for Pixel, Samsung, and OnePlus kernels. Those projects use device-specific sources and manifests and are more appropriate when a user needs a build aimed at one of those device families.

It is also a poor fit for a user who cannot recover from a failed boot independently. The README does not document a rollback command or automatic recovery mechanism. Preserving data, retaining a known boot image, and knowing the device's recovery method are prerequisites for using this build.

WildKernels Compared with Device-Specific Repositories

The clearest alternative identified by the README is one of WildKernels' device-specific repositories. `Sultan_KernelSU_SUSFS` uses Sultan sources for Pixel devices, `Samsung_KernelSU_SUSFS` uses Samsung sources and a Samsung manifest, and `OnePlus_KernelSU_SUSFS` uses OnePlus sources and a manifest. The difference is the source base. `GKI_KernelSU_SUSFS` starts from Google's generic GKI sources to cover many eligible devices, while the alternatives start from the relevant vendor source family.

That difference affects the work required from a user. A generic repository may reduce the need to maintain a separate codebase for many GKI devices, but it places more verification on the builder. The user must establish that the generic kernel fits the device and that the selected integrations work correctly. A device-specific repository has a narrower target, yet its source base may better reflect that device's original kernel requirements. The README provides no comparative tests or guaranteed support advantage.

A second alternative is an unmodified stock GKI kernel. That option avoids adding the repository's KernelSU-family implementations, SUSFS hiding, mount metamodules, and other features. For a user who does not need kernel-level modifications, the stock build is the narrower and less invasive choice.

Release Activity, Upgrades, and Licensing Boundaries

The repository was last pushed on 2026-10-17. That establishes recent repository activity, but the README does not provide a stable-release support period, upgrade policy, or device migration procedure. The named `nightly` release and other versioned releases show that output naming is part of the workflow. They do not explain whether builds are reproducible or whether one release can safely replace another on the same device.

Upgrade work includes more than downloading a newer artifact. Users must repeat the relevant build decisions, confirm that the new base kernel and patch level remain compatible, and preserve the ability to return to a known image. The README documents no in-project update command, rollback command, or automatic migration mechanism. Those operations belong to the external installation guide or the builder's own recovery procedure.

Repository metadata reports a custom license that GitHub cannot classify, while the README displays a GPL-3.0 badge and links to `LICENSE` and `THIRD_PARTY_NOTICES.md`. The exact terms should be read directly from those files rather than inferred from the badge alone. Incorporated projects may also have separate notices. Redistributing a derived kernel requires examination of `LICENSE`, `THIRD_PARTY_NOTICES.md`, and the terms of the selected KernelSU implementation, SUSFS integration, and other included projects. This is not legal advice.

Editorial conclusion

Experienced Android kernel builders should consider this repository when they need a configurable GKI 2.0 kernel with a selected KernelSU-family root implementation. Users requiring vendor-specific support, documented rollback, or turnkey flashing should first confirm that the linked installation guide covers their exact device and that they have a recovery plan. The deciding boundary is whether the device is GKI 2.0 compatible and whether the selected build can be reproduced and recovered safely.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WildKernels/GKI_KernelSU_SUSFS on GitHub