GKID on Android 16: KernelSU, SUSFS Variants and Safe Installation Guide

TL;DR: GKID can provide a practical gki kernelsu susfs stack on Android 16, but only when the device’s kernel, Kernel Module Interface and boot-image packaging match. Use stable GKID v26.07.26-r443, choose one compatible root variant, back up everything, prepare stock images, and never flash solely because the phone runs Android 16.

By the PrivacyPortal team

Last updated July 2026.

GKID combines a Generic Kernel Image (GKI) base with optional KernelSU-family root and SUSFS filesystem-hiding support. The current stable release uses Linux 6.1.175 on the android14-6.1-lts branch and can run on compatible Android 16 devices. Compatibility depends on the complete kernel and vendor interface, however, not the Android version shown in Settings. Unlocking the bootloader wipes the phone. A failed kernel flash can cause a bootloop or, without usable recovery files, leave the device effectively bricked. Back up first and retain the exact stock firmware.

GKI KernelSU SUSFS: what each component does

GKI is Android’s Generic Kernel Image architecture. It separates a common Android kernel from device-specific vendor modules through a defined Kernel Module Interface, or KMI.

KernelSU implements root access at kernel level. GKID offers variants for KernelSU, KernelSU Next, SukiSU Ultra and ReSukiSU, alongside unrooted Vanilla builds. The matching manager app controls which applications may receive root.

SUSFS adds kernel-level facilities for concealing selected filesystem artefacts and some abnormal boot-state indicators. It must be compiled into a compatible kernel. Installing a userspace configuration module cannot add SUSFS support to an unsupported kernel.

The GKID v26.07.26-r443 release, marked stable in July 2026, uses Linux 6.1.175 on android14-6.1-lts and offers SUSFS 2.2.0 and non-SUSFS variants.

Why an Android 14 kernel branch can run Android 16

The label android14-6.1 describes the kernel branch and KMI generation, not necessarily the Android userspace version. An Android 16 ROM may legitimately retain an android14-6.1 kernel.

That does not make every android14-6.1 image interchangeable. Confirm the device codename, full uname -r output, KMI generation, expected compression, boot-header format, vendor modules and target partition. A mismatch may prevent vendor modules from loading even when the headline Linux version is identical.

Google’s official Generic Kernel Image documentation explains the KMI contract between the GKI kernel and vendor modules. Treat that contract, plus device-specific packaging, as the compatibility boundary.

Image caption: Android userspace and the GKI kernel branch can have different version labels while remaining compatible through the KMI.

Which GKID variant should you choose?

Choose one root family and its matching manager. Do not install several managers or combine Magisk’s boot-image modifications with a KernelSU-based SUSFS setup.

In practice, start with Vanilla when device support is uncertain. If Vanilla bootloops, root hiding is irrelevant: the base kernel or packaging is incompatible. A Compat build may help where the release explicitly provides one, but it is not a universal repair.

Prerequisites and compatibility checks

• Back up photos, messages, authenticator recovery codes and application data somewhere off the phone.
• Obtain the exact stock firmware, including boot, init_boot, vendor_boot and vendor kernel module images where supplied.
• Install current Android platform tools and verify that adb devices and fastboot devices recognise the phone.
• Record adb shell uname -r, the device codename, build number and active slot before changing anything.
• Confirm that the bootloader is unlockable. Unlocking normally performs a factory reset and may affect warranty or support terms.
• Establish a tested recovery route: stock-image flashing, a compatible custom recovery, or a known method for changing slots.
• Remove existing Magisk, APatch or incompatible kernel modifications according to their own restoration instructions.

Our Android bootloader unlocking guide explains the wipe and recovery implications for beginners.

As of 27 July 2026, GKID v26.07.27-r444 was labelled a pre-release; v26.07.26-r443 remained the GitHub-marked stable build.

How to install GKID safely on a compatible Android 16 device

1. Finish the backup. Test that important files open from another device. Bootloader unlocking erases local data, while later flashing mistakes can make remaining data inaccessible.
2. Unlock using the manufacturer-supported procedure. Do not relock after installing GKID unless the device explicitly supports verified boot with that image. Relocking an incompatible modified image can cause a harder failure than an ordinary bootloop.
3. Match the release. Compare uname -r, the device codename and the maintainer’s compatibility notes. Android 16 alone is insufficient. Prefer stable v26.07.26-r443 over r444 unless you are deliberately testing the pre-release.
4. Select one asset. Choose Vanilla, KernelSU, KernelSU Next, SukiSU Ultra or ReSukiSU, then choose SUSFS or non-SUSFS only where the release offers that combination. Use the files listed in the appended Modules, apps & files to try section and verify any published checksum.
5. Prepare rollback files. Copy the complete stock images to the computer. Run fastboot getvar current-slot on A/B devices and record the answer. Do not assume the kernel belongs in boot: some devices package relevant components in init_boot or vendor_boot.
6. Use the asset’s specified installer. Flash an AnyKernel archive only through a supported recovery or kernel flasher. Flash a raw image only to the partition named by the release instructions. Do not improvise a generic fastboot command or flash the same image across several partitions.
7. Boot without making further changes. Allow several minutes for the first start. If the phone returns to the bootloader or repeatedly restarts, stop. Restore the stock image or switch to the known-good slot instead of repeatedly flashing modules.
8. Install the matching manager and verify. Open the KernelSU-family manager and confirm that the kernel integration is reported as working. Check adb shell uname -r, grant root only to a trusted test utility, and confirm that the SUSFS WebUI reports support when using a SUSFS build.

Image caption: A safe flashing workspace includes the matched GKID asset, platform tools, stock boot images and a written record of the active slot.

How to configure SUSFS without creating new problems

A kernel containing the SUSFS patch and a SUSFS companion module perform different jobs. The kernel supplies the capability; a module such as SUSFS-FOR-KERNELSU may provide scripts and a WebUI. If the manager displays “SusFS not supported”, adding more configuration modules will not repair an incompatible kernel.

For KernelSU Next, community-tested configurations commonly disable SUSFS logging, remove an obvious “KSU” string from the exposed kernel version, enable spoofing on boot and apply the WebUI’s make it sus action. In Custom SUSFS Settings, leave unfamiliar controls at their defaults and disable the ReVanced-hiding option unless you have a specific, tested reason to use it.

The custom hidden-path list is normally stored at /data/adb/susfs4ksu/sus_path.txt. Do not add paths blindly. Hiding a LineageOS overlay idmap path has caused horizontal display failures in real installations.

SUSFS-FOR-KERNELSU is not a Magisk module. Mixing Magisk hiding tools, KernelSU modules and multiple root daemons creates conflicts and additional detection surfaces.

What SUSFS can and cannot do for banking apps

SUSFS can reduce filesystem-based signs of root, but it does not guarantee that a bank, streaming service, game or workplace application will run. Applications may inspect the bootloader state, verified boot data, installed packages, hardware-backed attestation, unusual kernel properties or their own server-side risk signals.

Google Play Integrity results can also change without a local configuration change. A setup passing an integrity verdict today may fail after an application, Play services or server policy update. Never rely on root concealment for access to one essential financial service.

Keep an unmodified device or browser-based access route available for critical accounts. PrivacyPortal’s guide to how de-Googled Android phones work can help readers distinguish privacy-focused operating-system choices from root concealment.

SUSFS support is a kernel capability, not proof that a device will pass Play Integrity or any named application’s security checks.

Security, OTA and maintenance consequences

• Security: kernel-level root gives approved processes extensive control. A malicious module or mistaken root grant can compromise the entire device.
• Verified boot: an unlocked bootloader weakens protection against unauthorised physical modification and produces a visible warning on many phones.
• OTA updates: an update may overwrite the kernel, fail verification or boot with incompatible vendor modules. Restore stock components when the ROM’s update procedure requires them.
• Warranty and support: policies vary by manufacturer and country. Unlocking can complicate service even where statutory consumer rights remain.
• Maintenance: never carry a kernel across an OTA merely because both releases say Android 16. Recheck the KMI and device build after every firmware update.

Image caption: Kernel updates must be matched against each new firmware build rather than carried forward automatically.

Common GKID failure modes

• Immediate bootloop: wrong KMI, boot format, compression or device-specific patches. Restore stock, then reassess compatibility.
• Manager says unsupported: wrong manager family or a non-KernelSU build was flashed.
• “SusFS not supported”: the running kernel lacks the required SUSFS patch, or the intended kernel did not actually boot.
• Wi-Fi, camera or audio fails: vendor modules did not load correctly. A successful home-screen boot does not prove full compatibility.
• Root disappears after OTA: the update replaced the modified kernel. Verify the new firmware before installing a newly matched build.
• Apps still reject the device: detection may involve bootloader state, attestation or policy rather than visible root files.

Frequently asked questions

Can any Android 16 phone with a 6.1 kernel use GKID?

No. The complete KMI, device-specific vendor modules, boot packaging and maintainer support must match. A similar Linux version is not enough.

Should I install stable r443 or pre-release r444?

Use GKID v26.07.26-r443 for a stability-focused installation. Use v26.07.27-r444 only if its changes address your device and you can recover independently from a failed boot.

Do I need a separate SUSFS module?

The kernel must already include SUSFS. A companion module may still be needed for configuration scripts or its WebUI, depending on the chosen GKID variant and manager. It cannot add kernel support by itself.

Can I use SUSFS with Magisk?

Do not use the KernelSU SUSFS stack with Magisk. Choose either the matched KernelSU-family setup or a separately supported Magisk configuration, then remove the previous root method cleanly before switching.

Will KernelSU and SUSFS make every banking app work?

No. App checks and Play Integrity policies vary and can change remotely. No responsible guide can promise that this setup defeats a particular bank’s detection.

What should I do after a GKID bootloop?

Stop reflashing variations. Enter the bootloader or recovery, restore the exact stock image or boot the known-good slot, and confirm the phone is stable. Consider a documented Compat asset only after establishing why the standard build failed.