What Is SukiSU Ultra? The Modern KernelSU Variant, Explained

TL;DR: SukiSU Ultra is an open-source KernelSU fork that manages root access inside the Android kernel. It adds legacy-kernel support, App Profiles, Magic Mount-style modules, optional Kernel Patch Modules and SUSFS controls. It needs a compatible kernel and unlocked bootloader. Back up first because unlocking wipes the phone.

By the PrivacyPortal team

Last updated August 2026. Technical details checked on 22 August 2026.

In practical terms, SukiSU Ultra gives selected apps root access without relying on Magisk’s main userspace design. It is aimed at people who want kernel-level control, module support and stronger tools for limiting root visibility. Installing its manager app alone does not root a phone. Your device must run a compatible kernel or a correctly patched boot image. Compatibility is specific to the model, Android build and kernel. A mistake can stop the phone booting. Unlocking the bootloader erases user data and can affect updates, warranty support, banking apps and Play Integrity results.

What is SukiSU Ultra?

SukiSU Ultra is an active fork of the original KernelSU project. A fork takes existing open-source code and develops it along a separate path. It is not an official replacement maintained by the original KernelSU team.

The project places its root-control component in the Linux kernel. A companion Android app lets you approve root access, manage modules and set rules for individual apps. Its Android package name is com.sukisu.ultra.

If your search was “what is sukisu”, the simplest answer is this: it is a root manager plus kernel integration. It is not a custom Android ROM, an app-level exploit or a universal boot-image patch.

GitHub lists SukiSU Ultra v4.1.3 as the latest release, published on 2 June 2026; project development continued after that release.

Source code, releases and current notices are available from the official SukiSU Ultra GitHub project.

Caption: The manager shows kernel support, root status and installed modules from one screen.

SukiSU Ultra explained through its main components

The system has several parts which are easy to confuse:

• Kernel integration: the privileged code that makes kernel-level root possible.
• Manager app: the interface used to grant root and manage settings.
• ksud: the userspace daemon used by KernelSU-based systems to handle root operations.
• App Profiles: per-app rules which can restrict capabilities, user IDs and mount behaviour.
• Magic Mount-style modules: modules that change the visible file system without directly rewriting the system partition.
• KPM support: optional Kernel Patch Modules which can extend kernel behaviour on supported builds.
• SUSFS controls: options for kernels built with SUSFS, which can conceal selected mount and kernel artefacts.

The manager cannot add missing kernel features by itself. For example, SUSFS controls only work when the installed kernel includes compatible SUSFS code.

SukiSU Ultra vs KernelSU: practical differences

Area	SukiSU Ultra	Original KernelSU	Magisk
Root design	Kernel-level KernelSU fork	Kernel-level root	Boot-image and userspace-led root
Kernel requirement	Compatible integrated, GKI or legacy build	Compatible integrated or supported GKI build	Usually patches the device boot image
Root policy	App allow-list and App Profiles	App allow-list	Superuser prompts and configurable deny rules
SUSFS	Built-in controls when the kernel supports it	Depends on branch, kernel and add-ons	Not native to its main design
Module options	KSU modules, Magic Mount-style modules and optional KPMs	KernelSU-compatible modules	Large Magisk module ecosystem
Best fit	Supported devices where its extra kernel features are wanted	Users who prefer the original project path	Broad device support and familiar tooling

The key difference in any sukisu ultra vs kernelsu decision is device support. A well-maintained KernelSU build is safer than an unofficial SukiSU image made for a similar device. Similar model names do not imply compatible boot images.

How GKI affects compatibility

GKI means Generic Kernel Image. Android uses it to separate a common kernel core from many device-specific vendor modules. This can make compatible kernel distributions more practical, but it does not make every image universal.

Android’s GKI documentation defines GKI 2.0 for devices launched with Android 12 and a 5.10-or-newer kernel.

Check the Android version, kernel version, security patch, device codename and kernel module interface. The Android Generic Kernel Image documentation explains the architecture.

Older non-GKI devices normally need source-level kernel integration or a device-specific legacy build. Some maintainers distribute an AnyKernel3_SukiSU package for this purpose. Only use one which explicitly names your device and installed firmware.

How to install SukiSU Ultra on a supported device

This workflow covers the safe common path; the device maintainer’s instructions decide the exact image and partition.

1. Back up photos, messages, authenticator recovery codes and app data. Confirm that the backup can be opened elsewhere.
2. Record the exact model, codename, Android build and kernel version. Running adb shell uname -r can confirm the kernel version.
3. Download the SukiSU Ultra manager and a kernel or boot image made for that exact build. Use the “Modules, apps & files to try” section supplied with this guide.
4. Verify the file name, source and published checksum. Keep a matching stock boot image and the full factory recovery package.
5. Unlock the bootloader using the manufacturer’s documented process. Expect an immediate factory reset and a warning on each boot.
6. Choose only the route documented by the kernel maintainer. This may be a prebuilt boot image, an AnyKernel3 package or a legacy patching flow.
7. If the manager requests password-based legacy patching, use its stated patch function and store the password safely. Patch a clean boot image from the current firmware.
8. Where supported, test a boot image with fastboot boot filename.img. Flash it permanently only after a successful test and only to the documented boot partition.
9. Reboot and open the manager. Stop if it reports unsupported status, an unexpected kernel or a missing required feature.
10. Grant root only to an app you trust. Reboot once more, then complete the verification checks below.

Prerequisites to gather before installation

• An unlocked or unlockable bootloader.
• ADB and Fastboot from a current Android SDK Platform Tools package.
• A good USB cable and a charged phone.
• The exact stock boot image for the installed firmware.
• A device-specific SukiSU kernel, boot image or supported patch route.
• The current SukiSU Ultra manager app.
• A second device or computer holding recovery instructions and backups.

Read our Android bootloader unlocking guide before erasing a daily-use phone. Never flash an image chosen only by processor, screen name or a close model number.

Android’s official bootloader documentation states that unlocking must perform a factory data reset to prevent unauthorised access to user data.

How to verify the installation

Open the manager first. It should identify the expected SukiSU version and supported kernel state. A manager APK opening successfully is not proof that root works.

Install a reputable terminal or root-check tool, then request root once. Confirm that the manager displays a prompt and records the app in its allow-list. Deny the request afterwards if the app does not need ongoing access.

Reboot twice and check Wi-Fi, cameras, calls, storage, encryption and charging. Also test any essential work, banking and authentication apps. Do not wipe the stock recovery files until the phone has remained stable.

Caption: A successful check confirms the expected kernel before any optional hiding modules are added.

Modules and files worth understanding

The accompanying “Modules, apps & files to try” section may include the SukiSU Ultra manager, ReZygisk, TrickyStore and TrickyAddon. Some community configurations also use Play Integrity Fix by osm0sis.

Do not install every module at once. Start with the kernel and manager, verify stability, then add one module per reboot. This gives you a clear suspect when boot loops or app crashes begin.

ReZygisk provides a Zygisk-compatible environment for some KernelSU setups. TrickyStore and related add-ons alter parts of the device-attestation environment. Their behaviour can change after Android, Play services or server-side updates.

KPMs deserve extra care because they can modify kernel behaviour. Treat an unknown KPM like untrusted kernel code. Check its source, maintainer, release history and exact compatibility before loading it.

Banking apps and Play Integrity

Root hiding and platform integrity are separate problems. Hiding an su interface does not guarantee a valid hardware-backed verdict. An unlocked bootloader can affect Play Integrity even when no app receives root.

SUSFS, App Profiles and modules may reduce visible root signals. They cannot promise access to Google Wallet, Revolut or any specific bank. Apps use different checks, and those checks change without notice. Community reports are useful clues, not guarantees.

A result marked strong integrity also does not guarantee that an app will run. An app may inspect the bootloader state, installed packages, unusual mounts, accessibility services or its own risk service.

Test essential apps before making the phone your only device. Keep another way to make payments and recover accounts. Never weaken screen locks, encryption or verified downloads merely to satisfy an app check.

Real risks and common failure modes

• Boot loop: the image does not match the firmware, kernel modules or expected compression format.
• No radio, Wi-Fi or camera: vendor modules do not match the new kernel.
• Lost root after an OTA: an update replaces the modified boot image or changes its required kernel interface.
• Inactive-slot failure: an A/B update switches to a slot without the required kernel.
• Manager mismatch: a different KernelSU-family manager cannot control every fork-specific feature.
• Module conflict: two modules alter the same mounts, properties or Zygisk environment.
• Security exposure: a root app or module gains broad control over private data and the operating system.

Warranty handling varies by manufacturer and jurisdiction. Bootloader unlocking can still reduce vendor support or block official repair workflows. OTAs may fail or overwrite root. Restore matching stock images before updating when the maintainer requires it.

Caption: Keeping the matching stock boot image turns many failed kernel experiments into recoverable faults.

A safer troubleshooting order

If the phone still reaches Fastboot, avoid wiping data first. Reflash the matching stock boot image, then try to boot. Confirm that the image belongs to the active firmware and current slot.

If the base kernel boots but Android fails after adding a module, disable or remove that module through the supported rescue method. Do not stack more hiding tools over an unexplained fault.

For random reboots, collect kernel logs before changing the setup. Check whether the crash began after a module, OTA or manager update. A clean kernel with no optional modules is the useful baseline.

If device recovery feels unfamiliar, practise restoring factory firmware before installing root. Our practical guide to Android rooting risks covers the recovery concepts in more detail.

Who should use SukiSU Ultra?

SukiSU Ultra makes sense when your exact device has a maintained build and you need its App Profiles, legacy support, module design or SUSFS integration. It also suits experienced users who can recover partitions and inspect logs.

Keep original KernelSU when its official path supports your kernel and the fork’s extra features add no value. Choose Magisk when device support and its established module ecosystem matter more than kernel-level integration.

Avoid root on a work-managed phone, your only payment device or a handset you cannot restore. People who mainly want fewer Google services may prefer a supported privacy-focused operating system. PrivacyPortal treats root as an advanced ownership tool, not a basic privacy requirement.

Frequently asked questions

Is SukiSU Ultra the same as KernelSU?

No. It is an independent open-source fork based on KernelSU. Both use kernel-level root concepts and the ksud daemon, but their features, managers, supported kernels and development paths differ.

Can I install SukiSU Ultra by installing its APK?

No. The APK is a manager interface. Root needs compatible code in the running kernel or a correctly patched boot image. If the manager reports unsupported status, installing another copy will not add kernel support.

Does SukiSU Ultra work on every GKI phone?

No. GKI reduces some fragmentation, but kernel versions, KMI generations, vendor modules and firmware builds still matter. Use an image or package explicitly tested for your exact device and build.

Does SukiSU Ultra pass Play Integrity?

Not by itself, and no stable outcome can be promised. Bootloader state, firmware, hardware attestation, modules and server-side rules all affect the result. A passing integrity level also cannot guarantee that a particular banking app will work.

Does unlocking the bootloader delete data?

Yes. Android’s supported unlocking flow performs a factory reset. Back up first, including authenticator recovery codes and files stored only inside apps. Relocking can also wipe data and may brick a phone unless completely stock firmware is restored.

Can I use Magisk modules with SukiSU Ultra?

Some modules work through its module compatibility features, while others depend on Magisk internals or a specific Zygisk implementation. Check the module’s stated support. Make a backup and test one module at a time.

Is SukiSU Ultra safe?

It can be operated carefully, but root always expands the impact of a malicious or faulty app. Kernel modules carry especially high privilege. Use trusted releases, restrict root grants and keep Android security patches current.

The practical verdict

SukiSU Ultra is a capable modern KernelSU variant, not a universal root button. Its value comes from kernel-level access, precise app rules, flexible modules and support for SUSFS-enabled or selected legacy kernels.

The deciding factor is not which project has the longest feature list. It is whether a responsible maintainer supports your exact device and firmware. Back up, keep stock recovery files and verify the basic kernel before adding modules. If essential apps or reliable updates matter more than root, leaving the bootloader locked remains the safer choice.