TL;DR: GKID can run on compatible Android 16 devices using an android14-6.1 GKI kernel. Choose a build matching your root manager and select a filename containing “SuSFS” only if you want SUSFS v2.2.0. Back up first, retain the stock boot images, verify compatibility and prepare a tested recovery route before flashing.
By the PrivacyPortal team
Last updated July 2026.
GKID is a family of replacement Android kernels, not a universal Android 16 kernel. Release v26.07.21-r428 uses Linux 6.1.175 from the android14-6.1 long-term-support family and includes variants for Vanilla, KernelSU, KernelSU Next, ReSukiSU and SukiSU Ultra. Some builds include susfs, a kernel-level concealment system used by supported root solutions; others deliberately omit it. The critical compatibility test is the device’s kernel and Kernel Module Interface, or KMI, rather than the Android version displayed in Settings. GKID is unsuitable for devices on android16-6.12 or another KMI family.
Image caption: Android’s version number and the kernel’s KMI are separate compatibility checks.
What GKID is and what SUSFS changes
GKID packages several kernel configurations from the same project so users can choose an unrooted kernel or one integrated with a particular kernel-root implementation. KernelSU-family systems place important root functionality in the kernel and use a userspace manager application to control which apps receive root access.
SUSFS, short for “SU stealth filesystem”, adds kernel-level mechanisms intended to conceal selected mounts, paths and other signs of modification. It is not a complete security product, an automatic configuration service or a guarantee that an app will accept a modified phone. A compatible kernel supplies the feature; matching userspace components and configuration determine whether it is actually used.
GKID v26.07.21-r428, released on 21 July 2026, uses Linux 6.1.175 and includes SUSFS v2.2.0 only in archives whose filenames explicitly contain “SuSFS”.
In practice, installing a non-SUSFS GKID build and then adding a manager application cannot create missing kernel support. Conversely, flashing a SUSFS build does not mean every concealment option should be enabled. Over-broad path or mount rules can break applications and make troubleshooting substantially harder.
Check Android 16 kernel compatibility first
Android 16 can use more than one kernel generation. GKID r428 targets devices running a 6.1 kernel from the android14-6.1 family. It does not become compatible merely because the phone reports Android 16 or kernel 6.1 somewhere in its interface.
Check the kernel version with Settings > About phone > Android version > Kernel version, or connect Android Debug Bridge and run adb shell uname -a. Look for a 6.1 version and an android14-6.1 identifier. Then consult the device-specific community and the official GKID r428 release notes and assets for explicit support.
The Android Generic Kernel Image documentation explains how a common GKI kernel works with device-specific vendor modules. Those modules depend on a compatible KMI. A mismatch can prevent early boot even when the visible Linux version appears close.
Android 16 does not imply android16-6.12: supported devices may still use the android14-6.1 GKI family, which is the family targeted by GKID r428.
Do not flash GKID when the device uses android16-6.12, android13-5.15, a vendor-specific non-GKI kernel, or an unidentified KMI. A device-specific confirmation is stronger evidence than a report from another phone using the same chipset.
GKID variants compared
| Variant | Root approach | SUSFS requirement | Best fit | Main pitfall |
|---|---|---|---|---|
| Vanilla | No integrated kernel root | Normally none; follow the exact filename | Users wanting the GKID kernel without KernelSU-family root | It will not provide KernelSU root by itself |
| KernelSU | Standard KernelSU integration | Choose a filename containing “SuSFS” when required | Existing KernelSU setups with confirmed manager compatibility | Using a manager intended for a different fork |
| KernelSU Next | KernelSU Next integration | Available only in the corresponding SuSFS-labelled build | Users deliberately adopting the Next fork | Assuming all KernelSU behaviour is identical across forks |
| ReSukiSU | ReSukiSU-specific integration | Depends on the exact archive name | Existing ReSukiSU users following its documented stack | Mixing ReSukiSU kernel and manager generations |
| SukiSU Ultra | SukiSU Ultra integration | Choose its explicitly labelled SuSFS variant | Users who need SukiSU features and have verified device support | Treating “Ultra” as proof of wider hardware compatibility |
GKID r428 publishes ten builds across these families, reflecting combinations with and without SUSFS rather than ten interchangeable downloads. Read the complete filename. Do not select an archive from a shortened mirror label, screenshot or chat attachment.
Image caption: The correct archive matches the device KMI, root family and desired SUSFS state.
Before installing GKID
Back up everything before unlocking or flashing. Bootloader unlocking normally performs a factory reset and erases user data. Copy photographs, authenticator recovery codes, messaging backups and locally stored keys somewhere independent of the phone. Confirm that the backup can be opened.
- Charge the phone and use a reliable data cable.
- Install current Android platform tools on the computer.
- Record the exact current build number and active slot.
- Keep the matching factory package or stock boot, init_boot and vendor_boot images where applicable.
- Verify that OEM unlocking is permitted and understand the manufacturer’s recovery procedure.
- Remove the device PIN only if the chosen recovery’s documentation requires it; do not assume encrypted data will be readable in recovery.
- Download the exact GKID archive and matching manager application from the “Modules, apps & files to try” section supplied with this guide.
- Compare the file hash with an official checksum when one is published.
Unlocking and custom kernels may affect warranty support, over-the-air updates, Widevine status, corporate management, Play Integrity and banking or payment applications. Relocking with non-stock or mismatched partitions can permanently brick some devices. Return fully to verified stock firmware before considering a relock, and follow the device manufacturer’s instructions.
How to install a compatible GKID SUSFS build
This procedure is for an unlocked, confirmed android14-6.1 GKI device whose support community explicitly accepts the GKID flashable archive. Button combinations, partition layouts and recovery capabilities vary, so retain the device-specific restoration instructions beside you.
- Complete and test the backup. If the bootloader is still locked, unlocking it will wipe the phone. Finish that process using the manufacturer’s documented method, boot Android once and restore only what is needed for setup.
- Capture the baseline. Save screenshots or text showing the Android build, kernel version and root-manager version. In a computer terminal, check connectivity with adb devices, then record the result of adb shell uname -a.
- Prepare stock recovery files. Obtain factory images for the exact installed firmware. Preserve every boot-related image used by that device, not merely a random boot.img from another regional or monthly build.
- Select one matching archive. For r428, confirm android14-6.1 compatibility, then choose the KernelSU, KernelSU Next, ReSukiSU or SukiSU Ultra family matching the manager you intend to use. For SUSFS v2.2.0, the filename must explicitly contain “SuSFS”. Do not flash multiple variants consecutively.
- Remove incompatible kernel modules. Disable optional root modules, performance tuners and filesystem-altering modules before changing kernels. Keep only components explicitly required by the selected root family. This creates a useful clean baseline.
- Reboot into the supported flashing environment. Use the custom recovery or kernel-flasher method documented for the device and GKID archive. If using recovery, install the downloaded GKID ZIP without extracting it. Do not use a ZIP installer command on a raw image, and do not flash an archive to a guessed fastboot partition.
- Reboot once and wait. The first boot may take longer while Android rebuilds caches. Do not interrupt it merely because the boot animation runs for several minutes. If the device repeatedly restarts or remains unchanged beyond the device community’s normal first-boot window, begin recovery rather than repeatedly reflashing.
- Install or open the matching manager. Use the manager corresponding exactly to KernelSU, KernelSU Next, ReSukiSU or SukiSU Ultra. Confirm that it reports a working kernel integration. A manager reporting “unsupported” is a failed verification, even if another root-checking app detects something.
- Verify SUSFS separately. Open the manager or supported SUSFS userspace module and check that kernel SUSFS support is detected. Verify the reported SUSFS version where exposed. Do not infer success from the archive name alone.
- Test stability before concealment. Reboot again, test calls, cameras, Wi-Fi, Bluetooth, charging and biometrics, then add optional modules one at a time. Record each change so a later bootloop can be traced to a specific component.
Successful installation requires three independent matches: an android14-6.1-compatible device, the correct GKID archive, and a userspace manager built for that kernel-root family.
How to verify the installation
A successful Android boot is necessary but not sufficient. Compare adb shell uname -a with the recorded baseline and confirm the expected GKID kernel is active. Check that the manager recognises its kernel implementation, grants root only to an intentionally selected test app and can revoke that grant.
For SUSFS, use the status display provided by the compatible manager or SUSFS userspace component. The result should state that kernel support exists; a module showing “installed” while reporting an unsupported kernel means the feature is not operational.
Finally, inspect basic hardware and suspend behaviour. A kernel can boot yet still exhibit camera failures, broken Wi-Fi, excessive standby drain or random restarts because vendor modules are incompatible. Keep the device off critical duties until it has completed several normal reboots and a meaningful period of daily use.
Bootloop fixes and a safe recovery order
A bootloop immediately after flashing usually points to a KMI mismatch, incompatible vendor modules, the wrong GKID variant or an installation method unsuitable for the device. A bootloop that begins only after enabling modules more often implicates the newly added module or its configuration.
- Stop repeating the failed flash. Repeated attempts do not correct an incompatible KMI and may obscure which slot or image is active.
- Enter the bootloader or known-good recovery. Use the manufacturer’s documented key combination. Do not relock the bootloader.
- Disable the latest optional module. If the device offers a documented KernelSU-family safe mode or module-disable method, use the instructions for that exact manager. Procedures are not interchangeable across forks.
- Restore the original boot-related images. Flash only the stock images taken from the exact installed firmware, using the documented partition and slot commands for the device. Restore all partitions changed by the kernel installer.
- Try the project’s compatibility variant only when applicable. GKID releases may provide Compat builds for systems that bootloop with the standard build. A Compat variant can address particular module-loading differences; it cannot make android16-6.12 or another unsupported KMI compatible.
- Restore full factory firmware if necessary. Use the OEM’s official tool and matching package. Expect a possible data wipe. Seek device-specific help before erasing or changing slots when irreplaceable data remains.
Image caption: Recovery should move from disabling the latest change to restoring exact stock images.
SUSFS, Play Integrity and banking apps
SUSFS can reduce some observable signs of root or modified mounts, but application checks are layered and change without notice. An app may inspect bootloader state, hardware-backed key attestation, Play Integrity verdicts, installed packages, unusual processes, developer settings or behavioural signals.
No SUSFS, KernelSU or module combination can be promised to satisfy a particular bank, wallet, game or workplace application. A configuration working today may fail after an app, Google Play services or server-side policy update. Adding more concealment modules can also expand the attack surface and create contradictory hooks.
If dependable banking or corporate access is essential, the lowest-risk answer is a locked, unmodified device running supported firmware. Readers considering a cleaner everyday handset can also explore PrivacyPortal’s guide to de-Googled Android phones, where privacy does not depend on disguising root from third-party applications.
Common GKID and SUSFS pitfalls
- Choosing by Android version alone: Android 16 spans different kernel and KMI families.
- Ignoring the complete filename: SUSFS is present only when “SuSFS” is explicitly included.
- Mixing root families: A KernelSU Next manager is not automatically correct for standard KernelSU or SukiSU Ultra.
- Keeping old modules enabled: A module built around a previous kernel or root implementation can trigger a bootloop.
- Flashing to a guessed partition: Modern devices distribute boot components across different partitions and slots.
- Using mismatched stock images: Restoring an image from another firmware revision can leave the device unbootable.
- Relocking too early: Relocking before restoring verified stock firmware can turn a recoverable failure into a hard brick.
- Equating concealment with security: Granting root gives approved processes extensive control; hiding evidence of root does not reduce that privilege.
Frequently asked questions
Does GKID work on every Android 16 phone?
No. GKID r428 targets compatible devices using the android14-6.1 GKI family. It is not intended for android16-6.12 or unrelated KMI families. Confirm the kernel, KMI, device support and release notes before flashing.
Does every GKID variant include SUSFS?
No. SUSFS v2.2.0 is included only in r428 assets whose filenames explicitly contain “SuSFS”. Root-manager branding alone does not confirm SUSFS support.
Can I add SUSFS to a non-SUSFS kernel with a module?
Not as a complete substitute for the kernel patch. Userspace components can configure supported functionality, but they cannot provide kernel-level SUSFS mechanisms when the running kernel lacks them.
Which GKID root variant should I choose?
Choose the variant matching the root family you have deliberately selected and whose manager supports that build: KernelSU, KernelSU Next, ReSukiSU or SukiSU Ultra. Vanilla is appropriate when integrated kernel root is not wanted. Device compatibility takes priority over feature preference.
Will SUSFS make banking apps work?
There is no reliable guarantee. Banking and payment apps use changing combinations of local and server-side checks. Never rely on a guide, module or kernel to defeat a specific app’s detection.
What should I do if GKID bootloops?
Enter the documented bootloader or recovery environment, disable the latest optional module if possible, then restore exact stock boot-related images for the installed firmware. Consider a documented Compat build only after confirming the device still matches android14-6.1. Do not relock while modified partitions remain.
Will GKID stop over-the-air updates?
It can. An OTA may reject modified boot partitions, overwrite the custom kernel or leave the inactive slot with an incompatible combination. Restore stock images and follow device-specific update instructions before accepting an OTA. Keep a current backup because update behaviour varies by manufacturer.
