The question is really about trust#
A new F-Droid Forum thread asks a simple question: why is KernelSU not available on F-Droid?
The post is short. The user says KernelSU is open source and appears to be GPLv3-licensed, and contrasts it with APatch, which is already available through F-Droid. Their practical reason is not abstract. APatch, they say, cannot hide from one app they use, while KernelSU can.
The stronger point is about distribution. The user prefers F-Droid because they have more confidence that an APK was built from the source they can inspect. GitHub releases, by contrast, can contain whatever binary a maintainer uploads.
That is the whole public fact pattern in the collected source. There is no official F-Droid decision in the excerpt. No maintainer response is included. No rejection reason is stated.
What is known#
KernelSU is being discussed as an open-source Android root solution. The forum poster believes it is licensed under GPLv3, but the source text phrases that as a question, not as a confirmed legal finding.
APatch is mentioned as available on F-Droid. The user treats it as a nearby comparison because both tools sit in the Android root/modification space. The user also says APatch does not meet their needs for hiding from a specific app, while KernelSU does.
The post also captures a common reason people use F-Droid: build provenance. F-Droid is not just another app store. Its value proposition is that apps are built from published source under a process users can inspect more easily than a random binary upload.
That matters more for root tooling than it does for many ordinary apps. A root manager or kernel-level modification tool sits close to the device trust boundary. If the binary differs from the source, the user has a bigger problem than a cosmetic mismatch. The tool may control privileged execution, app visibility, modules, and device integrity signals.
What is not known#
The source does not explain why KernelSU is not on F-Droid.
There are several possible reasons an app or tool might not appear in F-Droid: packaging complexity, unsupported build steps, dependencies, anti-features, reproducibility problems, signing model conflicts, maintainer capacity, or no one having submitted a workable package. But none of those reasons is confirmed here for KernelSU.
It would be wrong to turn the absence into a verdict. Not being on F-Droid does not prove a project is unsafe. It also does not prove F-Droid rejected it. It may simply mean nobody has completed the work needed to package and maintain it under F-Droid’s rules.
It would also be wrong to treat GitHub releases as automatically unsafe. Many reputable projects ship binaries there. The risk is different: users are usually trusting the maintainer’s uploaded artifact, the release process, and any available signatures or checksums. That is not the same trust model as a repository that builds from source through its own infrastructure.
Why this matters for Android root users#
Root tools are not normal apps.
They often need privileged access, kernel interaction, boot image changes, module loading, or mechanisms that affect how other apps perceive device state. A small supply-chain mistake can become a full-device compromise.
The user’s comment about hiding from an app also points to the messy reality of rooted Android. Some users want root for control, backup, firewalling, automation, or device repair. Some apps respond by detecting root and refusing to run. Tools then compete not only on features, but on stealth and compatibility.
That creates a hard trust problem. A tool that hides well must interact with sensitive parts of the system. The better it is at modifying what apps can see, the more carefully users should examine where the binary came from and how updates are delivered.
For this class of software, the download source is part of the security model.
What readers can check next#
If you are deciding whether to use KernelSU, APatch, or any similar Android root tool, start with the boring checks.
- Look for the official project repository and current documentation.
- Check the license in the repository, not only in a forum post.
- See whether release artifacts are signed, reproducible, or matched to tagged source.
- Check whether the project documents its build process.
- Review open issues around security, device compatibility, and update failures.
- If F-Droid availability matters to you, search F-Droid metadata, merge requests, and issue trackers for packaging attempts or blockers.
For F-Droid specifically, the useful question is not only “why is it missing?” It is “what would be required for this project to be built and maintained there?”
That answer usually lives in packaging metadata, build constraints, dependency choices, and maintainer discussion. A two-post forum question is a starting signal, not a conclusion.
Practical takeaway#
The forum thread does not establish a controversy. It exposes a real user concern.
Android root users are being asked to trust powerful binaries. F-Droid reduces one kind of trust by building from source under a public process. GitHub releases can be fine, but they shift more trust back to the project’s release pipeline.
Until there is a clear F-Droid packaging discussion or maintainer answer for KernelSU, the safest reading is narrow: users want KernelSU through a build-from-source distribution channel, and the current source does not say why that has not happened.