TL;DR: WildKernels compatibility depends on your device’s complete Kernel Module Interface family and vendor modules, not merely its QPR1 or QPR2 label. Back up first, check uname -r, match the release exactly, and restore stock boot-related images after an OTA. Try the normal WildKernels build before any module-loading bypass.
By the PrivacyPortal team
Last updated August 2026.
A QPR change does not prove that a WildKernels build is compatible or incompatible. QPR means Quarterly Platform Release. It can change the kernel, vendor modules, boot images or none of them. Check the complete kernel identity and the release notes instead. A kernel and ROM source mismatch can stop Android booting. It can also break Wi-Fi, recovery, cameras or other hardware.
Back up your files to another device before changing anything. Unlocking the bootloader wipes the phone. Kernel work can also affect warranty support, over-the-air updates, banking apps and Play Integrity. No kernel, root manager or module can guarantee that a specific app will accept a modified phone.
What determines WildKernels compatibility?
WildKernels compatibility rests on three linked requirements: the kernel’s KMI family, the device’s vendor modules and the project’s stated device support.
KMI means Kernel Module Interface. It defines how loadable modules talk to the kernel. Android’s Generic Kernel Image, or GKI, makes this interface more stable. It does not make every GKI kernel interchangeable.
Run adb shell uname -r while Android is booted. Save the complete output, including its Android generation and build suffix. Do not compare only “5.10”, “5.15” or “6.1”. Two kernels can share that base version while using different module interfaces.
Then read the matching WildKernels release notes. Confirm the expected KMI, supported root implementation and device restrictions. The Android GKI documentation explains how Google separates the generic kernel from vendor-specific modules.
Android 12 introduced GKI 2.0, with a stable KMI between the generic kernel and compatible vendor modules.
The compatibility check should compare the phone’s full kernel identity with the selected release.
WildKernels QPR1 compatibility and QPR2 compatibility
WildKernels QPR1 compatibility cannot be judged from “QPR1” alone. The same rule applies to WildKernels QPR2 compatibility. Those labels describe Android platform updates, not a universal kernel interface.
An OEM can ship a QPR update with a new boot image, kernel build or vendor module set. Another device may keep the same compatible KMI. Custom ROM maintainers can also merge platform and kernel changes on different schedules.
For that reason, a build that boots on one QPR2 ROM may fail on another. A QPR1 kernel may even remain usable after an update when its KMI and vendor requirements have not changed. Only use that combination when the kernel developer supports it.
After any ROM update, restore or flash the stock boot-related images supplied for that exact ROM build. Let the phone boot once in its stock state. Record the new uname -r result before choosing another kernel.
This clean baseline avoids blaming QPR when the real cause is an old boot, init_boot, vendor_boot or vendor_dlkm image.
How to diagnose a kernel and ROM source mismatch
A kernel and ROM source mismatch often appears as a boot loop. It can also cause faults after Android starts.
| Symptom | Likely cause | First safe action |
|---|---|---|
| Immediate boot loop | Wrong KMI or unsupported device | Restore the exact stock boot images |
| Boots without Wi-Fi | Vendor module mismatch | Restore stock kernel and vendor modules |
| Recovery no longer starts | Recovery and vendor-module conflict | Use the supported bootloader recovery route |
| KernelSU manager shows no support | Wrong KSU integration or manager | Check the release’s required manager |
| Failure after an OTA | Old kernel retained with new ROM files | Return every boot component to the new stock set |
| Random drain or poor performance | Module conflict or unsuitable build | Test the stock kernel without modules |
Capture evidence before changing more parts. Save uname -r, the ROM build number and Android security patch date. If possible, collect a kernel log or boot log using the method supported by your device.
Change one variable at a time. Stacking a new kernel, root manager and several modules makes the failure hard to isolate.
How to install a compatible WildKernels release
Use this controlled process on your own supported device, with the stock recovery files ready.
- Copy photos, authentication data, downloads and app exports to another device.
- Install the latest stable Android SDK Platform-Tools from Google. Confirm that adb devices detects the phone.
- Record the ROM build, security patch and full output from adb shell uname -r.
- Download the factory or ROM package for the exact installed build. Extract its stock boot, init_boot, vendor_boot and relevant vendor images.
- Check whether the bootloader is unlocked. If it is locked, understand that fastboot flashing unlock normally erases all user data.
- Choose the right WildKernels release by matching its full KMI requirements and device notes. Start with the normal build.
- Disable optional root and kernel modules. Follow the project’s removal steps when switching from Magisk to a KernelSU-based kernel.
- Flash the AnyKernel3 archive with a supported kernel flasher app or supported custom recovery. Never guess a partition name or flash a ZIP as a raw image.
- Reboot Android and allow extra time for the first start. Do not keep force-restarting a device that remains on the boot screen.
- Verify the kernel, root manager and core hardware before adding modules or testing a bypass build.
Prerequisites and files to keep nearby
You need a charged phone, a sound USB cable and a computer with current Platform-Tools. Keep the exact stock ROM package on the computer. Make sure you know the device’s documented recovery or unbrick procedure.
The “Modules, apps & files to try” section includes relevant testable files. One archived release is 6.1.145-android14-2025-08-AnyKernel3.zip from WildKernels GKI KernelSU SUSFS r4. Its name is not proof of support for Android 16, Pixel 9 or an unrelated 6.1 device.
The r4 archive is named 6.1.145-android14-2025-08-AnyKernel3.zip; its supplied release evidence does not establish Pixel 9 or Android 16 compatibility.
How to verify the installation
Run adb shell uname -r again and compare the result with the release notes. Open the required KernelSU, KernelSU Next or SukiSU Ultra manager. Confirm that it recognises the installed kernel.
Test Wi-Fi, Bluetooth, mobile data, cameras, audio, charging and sleep. Then check recovery access using the device maker’s supported method. Do this before storing new data on the phone.
Test important apps without assuming they will work. An unlocked bootloader, root state or altered kernel may trigger Play Integrity and local anti-tamper checks.
A successful test covers normal boot, recovery, hardware and the intended root manager.
When to consider the module-loading bypass
The normal WildKernels image should be the first test. A module-loading bypass is a compatibility tool, not a default performance option.
Consider the project’s bypass only when the normal build matches the documented KMI but cannot load the required vendor modules. Confirm that WildKernels recommends the bypass for that exact failure. Keep the stock images available throughout the test.
A bypass cannot correct arbitrary kernel and ROM source mismatch problems. It cannot supply missing device drivers or make an unsupported device safe. It may also hide the first visible symptom while leaving recovery or another boot mode broken.
If the normal build starts Android but loses Wi-Fi, camera access or recovery, return to stock. Do not install concealment modules in an attempt to fix driver faults.
Users who only need conventional root may find Magisk easier on an unsupported kernel. KernelSU needs kernel-side support. A Magisk-patched boot.img is not a KernelSU kernel.
KernelSU forks and GKI requirements
WildKernels releases may integrate KernelSU, KernelSU Next or another fork. Match the manager app to the integration named by the release. Similar architecture does not make every manager and kernel pair interchangeable.
The official KernelSU installation guide separates GKI installation from builds for older or non-GKI kernels. GKI 2.0 devices commonly use kernel 5.10 or later. Older devices may require a device-specific custom kernel.
KernelSU’s official guide lists Android GKI 2.0 devices with kernel 5.10 or newer as officially supported.
KernelSU Next and SukiSU Ultra use the same broad kernel-root model, with privileges handled in kernel space and by a userspace daemon. Their versions, managers and module expectations can differ.
Do not install a KernelSU build over an active Magisk setup unless the kernel maintainer documents that path. Conflicting root components can cause boot faults, battery drain or confusing manager status.
Recovery and Xiaomi-specific risks
Recovery is part of the compatibility decision. A kernel is not fully usable if Android boots but the supported recovery path fails.
A WildKernels developer discussed vendor-module debloat intended to improve boot speed and performance slightly. The proposed change could break recovery on compatibility-focused devices such as some Xiaomi models. The kernel could not yet distinguish recovery mode from normal boot mode in that setup.
Treat this as a release-specific warning, not a claim about every Xiaomi phone. Read the current notes before flashing. Test recovery while stock restoration files and a working computer are available.
Do not rely on a custom recovery as the only repair route. Learn whether the device supports fastboot, fastbootd, a manufacturer download mode or another documented restore process.
The risk is greater when vendor modules live across several partitions. Restoring only boot.img may leave a mixed set from two ROM builds.
Recovery testing can reveal a vendor-module conflict that normal Android boot does not show.
A practical release decision framework
Use four gates to choose the right WildKernels release. Stop when any gate fails.
- Device gate: The release must name the device or clearly support its GKI class.
- KMI gate: The full KMI family must match. A shared base Linux version is not enough.
- Vendor gate: Required vendor modules must load in Android and recovery.
- Root gate: The kernel integration must match the intended manager and modules.
QPR is useful context after these checks. It is not a substitute for them. This framework gives wildkernels compatibility a testable meaning instead of treating ROM labels as proof.
For a lower-maintenance device, consider whether root is needed at all. PrivacyPortal’s guide to installing GrapheneOS explains a security-focused route for supported Pixel phones. Our guide to de-Googled phones covers options that do not depend on a custom kernel.
Common pitfalls that cause avoidable failures
- Matching only the Android version, QPR label or first kernel number.
- Flashing a release because another phone uses the same chipset.
- Keeping an old kernel across an OTA without checking the new KMI.
- Restoring boot while leaving mismatched vendor_boot or vendor modules.
- Using a bypass before testing the normal WildKernels image.
- Combining Magisk, KernelSU and APatch components without documented support.
- Adding performance, concealment and filesystem modules before the first clean boot.
- Assuming a successful Android boot proves that recovery works.
- Building with the newest Clang release instead of the kernel tree’s known-working compiler.
- Assuming root will pass a bank’s checks or Play Integrity.
For kernel builders, compiler choice is a real diagnostic variable. Rebuild the unchanged tree with its known-working Clang version first. If that boots, compare configuration and compiler-specific patches before testing newer toolchains. There is no universal “best” Clang version for every tree.
Frequently asked questions
Does QPR2 always need a different WildKernels build?
No. WildKernels QPR2 compatibility depends on the KMI and vendor-module set delivered by the ROM. Check uname -r and the release notes after updating. Restore the current ROM’s stock boot-related images before testing a custom kernel.
Can I use a QPR1 kernel on QPR2?
Only when the complete KMI, vendor requirements and release guidance still match. The QPR labels alone cannot answer this. An unsupported mix may boot-loop or fail later in Wi-Fi, cameras, sleep or recovery.
Why does Android boot while recovery fails?
Normal Android and recovery can need different module behaviour. Vendor-module removal or loading changes may work during a normal boot but fail in recovery. Return to stock if the release does not explicitly support that recovery path.
Can I install KernelSU with a Magisk-patched boot image?
No. KernelSU needs support inside the kernel. A Magisk-patched image provides a different root method. Use the WildKernels build and manager combination documented by its maintainer, or use Magisk when the device lacks a suitable KernelSU kernel.
Will WildKernels make banking apps work?
There is no guarantee. Apps may inspect bootloader state, root traces, Play Integrity results and their own risk signals. Checks can change without notice. Never depend on a custom kernel to defeat a particular bank’s controls.
What is the fastest way to recover from a boot loop?
Stop repeated boot attempts and restore the exact stock boot-related images for the installed ROM build. Use the device’s documented fastboot or recovery procedure. Do not erase extra partitions or flash files from a different update merely because their names match.
What should I save before the next OTA?
Save personal backups, the current uname -r output, the ROM build number and clean stock images. After the OTA, let the stock kernel boot once. Recheck wildkernels compatibility before reinstalling any custom kernel or root modules.
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
