An automated kernel builder for Oppo, OnePlus and Realme Snapdragon 8 Elite devices

The project exists because the vendor kernel build is hostile to newcomers

The repository describes itself as an automatic kernel builder for Oppo, OnePlus and Realme Snapdragon SM8750 series devices, and the README sets out three concrete problems it set out to solve. First, the vendor opens its kernel source only halfway, so some kernel code cannot be compiled through the configuration xml files that ship with it, and in some cases no configuration file exists at all. Second, the vendor build uses Bazel, which the author describes as unstable and inefficient, producing errors that are hard to explain and, in the author's words, unfriendly to newcomers because workable fixes are almost impossible to find. Third, and this is the interesting one, the vendor modified the f2fs filesystem code, which means that on these devices a GKI kernel flashed without wiping the data partition may fail to boot normally. Those three problems set the scope of the project: it is not a general purpose kernel build system, it is an attempt to make one vendor's kernels buildable and flashable by people who are not full time kernel engineers.

Two build modes, and the GKI one is still on the to-do list

The design gives you a choice between two source trees. The OKI mode compiles the official vendor source, which keeps the vendor drivers and scheduler behaviour, while the GKI mode compiles the generic Google kernel source, which is described as more compatible because a GKI kernel can be flashed without matching the exact minor kernel version. The plan was to port the vendor f2fs source into the GKI build so that a GKI kernel would boot with the data partition intact, exactly like the official OKI kernel, without needing that data wipe that the README describes as a requirement in the original setup. The implemented list confirms the OKI side is done for both chip families, with the SM8750 kernels built from OnePlus 13, OnePlus 13T, OnePlus Pad2 Pro and other sources across several 6.6 kernel versions, and the MT6991 kernel built from OnePlus Ace5 source at 6.6.50. The universal GKI kernel for SM8750 still sits in the not yet implemented section, so the compatibility argument in favour of GKI is currently theoretical for this project. A reader should treat the OKI path as the working one and the GKI path as the direction of travel.

Swapping Bazel for LLVM/Clang 18 and pruning vendor sources

The technical centre of the project is the toolchain change. Instead of the official Bazel compiler, the scripts build with LLVM/Clang 18, and they exclude the unnecessary vendor sources from the build so they do not take part in compilation. The author reports that this cuts build time by nearly two thirds compared with the official compiler, which needed more than an hour per full build, and that the build is more stable with output logs that are easier to maintain and debug. On top of that sits a caching layer, the author's own ccache-ECS project, plus a set of build pipeline optimisations, which together keep a build at roughly six minutes. The caching behaviour has a condition worth knowing before you plan around it: the first build pulls a public prepopulated cache, and from the second build onwards, as long as you do not change many configurations, single builds take about six minutes, but if the cache is not called for two weeks it is cleared automatically and the cache has to be rebuilt. On top of the toolchain, the README lists O2 optimisation to improve runtime performance, and the project also adds the Fengchi scx scheduler from the vendor kernel across the 6.6 series, which on devices that support the official Fengchi kernel gives the full original scheduler behaviour.

Root solutions, filesystem patches and network and IO tuning

The feature set is broad and enthusiast oriented, and a few entries are worth reading closely. Multiple root implementations can be selected, with ReSukiSU, SukiSU Ultra, KernelSU Next and the original KernelSU all listed as options, and the note about hook modes explains that the older manual, kprobes and syscall hook options have been abandoned because the newest KSU releases use inline hooks. The lz4 1.10.0 and zstd 1.5.7 compression update and optimisation patches are credited to two other contributors with the 6.6 patches redone by the project author. Beyond that there are optional TCP congestion control algorithms including BBR and Brutal, the ADIOS IO scheduler ported from another project, network connection performance options that exist to support programs needing ipset and advanced iptables features, support for Mountify modules, and Re:Kernel integration for working with Freezer and NoActive to reduce power use. Two entries stand out for what they protect rather than what they add. There is a baseband guard patch credited to another contributor, described as effective at preventing malicious factory-reset scripts and programs from damaging system partition data, and Droidspaces containerisation support, described as a more lightweight container implementation than Docker or LXC for a portable full Linux environment. The pending list names zram built in so no external zram.ko module is needed, Nethunter wireless adapter monitoring mode, and kexec support for hot switching kernels at runtime.

What the repository actually contains, and how the builds are delivered

The top level of the repository gives a fair picture of the shape of the work. There is a .github directory holding the workflow definitions for online builds, a local directory that holds the shell script path for building on your own machine, a lib directory, a droidspaces_patch directory, an other_patch directory, a zram_patch directory and a zram.zip archive. So the delivery model is dual, with a GitHub Action that builds online and a local shell route that builds on a machine you control, which matters because a kernel build wants a Linux host with a specific toolchain, and doing it in a hosted runner avoids setting that up. The primary language of the repository is Shell, and there is no homepage declared. On licensing, the repository listing shows no LICENSE file at the top level, which is a real consideration for anyone who intends to redistribute a built kernel or reuse the scripts beyond personal use. The project also leans on other people's work, and the acknowledgements section links the root solutions, the susfs module, the KernelSU patches, the manual hook patches, the original KernelSU and the baseband guard module, plus a note that the GKI kernel build script is still to be decided and that an earlier localised build script has been retired. The repository is not archived and the last push was on 2026-10-05, although there are no tagged releases, so there is no version history to pin to.

Where this build script is the wrong tool

The scope limits are severe enough to state plainly. This is not a general kernel build system, and it does not cover other chip families, other vendors or other kernel versions. The README explicitly says that for other devices running the same kernel version but not SM8750, you should test it yourself, and that some devices are fully compatible. In practice, a kernel built from a source tree for one model and flashed on another can simply fail to boot, and recovering from that is a problem you solve with a computer, a cable and a backup, not with documentation. The device coverage itself is narrow. The implemented SM8750 kernels are drawn from a handful of OnePlus sources across 6.6.30, 6.6.56, 6.6.57, 6.6.66 and 6.6.89, and the MT6991 kernel from OnePlus Ace5 source at 6.6.50, so you need to check which kernel version your own phone ships. The build also assumes the source and configuration set the scripts expect, and the stated purpose of the whole exercise includes working around vendor source that is only half published. A second limitation is that the fast build depends on a public prepopulated cache and on your local cache surviving, so the advertised six minute build is a steady state rather than a guaranteed one.

A hand rolled build script versus the vendor toolchain

The realistic alternative is what the vendor already gives you, which is a Bazel based build that works, is documented by the vendor, and takes more than an hour. The difference in approach is not about which compiler is better in the abstract, it is about who absorbs the failure. With the vendor setup, a build error lands in Bazel output that you then have to interpret with the vendor's own configuration files as the reference, and the author's complaint is that the searchable answers are almost nonexistent. With these scripts, the compiler is a mainstream one you can debug with ordinary tooling, the vendor sources that cause trouble are pruned, and the same build can run in a hosted GitHub Action or on your own box. Against that, a hand maintained script carries the maintenance burden itself. When the vendor updates a kernel version, someone has to update the source list, the patches and the configuration, and this repository does that work continuously, with the last push on 2026-10-05 and a pending list that includes the GKI port, zram integration, Nethunter monitoring mode and kexec. The honest summary is that this project converts a vendor build you cannot debug into one you can, at the price of depending on a single maintainer for a device specific tool.

Editorial conclusion

Adopt this build script if you own one of the listed Oppo, OnePlus or Realme SM8750 or MT6991 devices and want a kernel with the Fengchi scx scheduler, KernelSU variants and a faster build than the vendor Bazel setup. Skip it if you need a generic kernel toolchain or if your device kernel version is not one of the ones named in the README, since ports to other versions are left to you to test. Verify first which kernel source and version your exact model runs, whether you can restore a working image when a build does not boot, and that you read the licence position yourself, since the repository does not declare one.

Frequently asked questions

Official sources

1. cctv18/oppo_oplus_realme_sm8750 on GitHub
2. Issues
3. README