Most mobile operating systems inherit Android’s architecture, even when the visible interface looks different. Nuxel takes another route: a Linux system with a focused userspace, built without Android framework layers. That choice shapes how the operating system is assembled, diagnosed, and tested.
No libhybris, no AOSP abstractions
A conventional Linux-on-phone project often places a compatibility layer between Linux and Android-oriented hardware components. libhybris is the best-known example. Nuxel does not use it. There is no AOSP framework underneath the interface and no libhybris bridge translating between two different ideas of how a phone should work.
Every compatibility layer is also an agreement to preserve somebody else’s assumptions. That can be the right trade-off for a project that needs existing Android drivers or applications. For Nuxel, it would mean carrying two architectures at once: the Linux system the project wants and the Android-shaped system required to reach the hardware.
Instead, Nuxel builds on Linux and a focused userspace. The graphical shell is Phosh, and the base system is Fedora. The target path uses Linux 6.12 LTS; the Galaxy S10+ currently runs Samsung’s vendor 4.14.253 kernel while that port is brought up. Hardware access is approached through Linux interfaces, not through an Android framework. Phones remain complicated, but an entire class of translation and compatibility questions leaves the critical path.
A smaller surface to reason about
Every inherited layer is a layer someone must understand when something fails. A smaller surface makes it easier to answer basic engineering questions. Where did this value come from? Which component owns this device? Which interface is responsible when a sensor stays silent?
Auditability improves for the same reason. A smaller stack is not automatically auditable, but it gives auditors fewer boundaries to cross and fewer hidden contracts to reconstruct. The project can describe its integration points and test them directly, rather than inspecting a symptom in one layer that originated in another layer nobody intended to expose.
The security argument should be stated carefully. Removing compatibility code reduces the number of places where assumptions can hide. It does not guarantee that the remaining code is correct, and it does not make the operating system unbreakable. Nuxel’s safety claims come from specific mechanisms and tests, not from the phrase “zero Android DNA” by itself.
The testing argument is practical. Nuxel’s L1–L6 release gates move from static analysis and unit tests through integration, virtual machines, live phones, and owner-run physical tests. A focused architecture gives those gates clearer targets, and each gate can state what it verifies and what remains unproven.
What from-scratch means in practice
From-scratch does not mean rejecting useful upstream Linux projects. Nuxel is not a reimplementation of a kernel, a display server, or an entire desktop environment. It means owning the integration: choosing components that fit the Linux model, connecting them deliberately, and documenting where the project ends and an upstream project begins.
Writing every line ourselves would not automatically be more trustworthy; it is often less tested and harder to maintain. Nuxel uses Linux and established userspace components, then takes responsibility for the parts that make them work together on a phone. That includes device enablement, the boot and update model, release engineering, and decisions about which capabilities are ready to claim.
When something breaks, the investigation can follow Linux interfaces and project-owned integration code. There is no need to first determine whether an Android abstraction, a compatibility shim, or the Linux layer is responsible.
Why it matters
A phone operating system is a long-lived commitment. Devices remain in use for years, upstream projects change, and security fixes must be applied without rebuilding the world around them. An architecture with fewer inherited layers is easier to maintain because individual pieces can be replaced without unwinding a chain of compatibility promises.
For users, the result should be a system they can inspect and a project that is candid about its limits. For contributors, it should be a stack where a fix can be made at the right level.
Zero Android DNA is therefore an architectural commitment, not a guarantee of quality. It gives Nuxel a smaller system to reason about and a clearer basis for testing. The claims still have to be earned one gate at a time.