Pokélinux

Building an Omarchy smartphone system with native Rust services. Pixel 10 first.

The target is Arch Linux ARM, Hyprland and native phone apps, with shared Rust services behind hardware-specific backends. Google's matched Pixel kernel, modules and firmware provide the initial device-support baseline.

Current status: working VM prototypes and installed ARM service checkpoints. No physical phone has been tested, and there is no verified bootable phone image.

See it running

These are real, unedited x86 VM captures at the Pixel 10 display profile: 1080 × 2424 pixels, 422 PPI and 420 logical density. The upstream debug-launch banner remains visible.

The same Messages window follows an original Omarchy theme change from Tokyo Night to Catppuccin Latte while preserving its local history. Both its Messages and appearance client engines run in Rust; Qt renders the interface. The two messages are authored test data; this checkpoint does not send or receive SMS. Theme and permission test.

Messages · Tokyo Night	Same window · Catppuccin Latte

Settings now controls a real virtual network through the Rust service stack. Enable exchanges packets; closing Settings leaves the connection working. A fresh app instance observes that connection, exchanges another packet, then Disable removes the address and stops traffic. This passes in an x86 VM with explicit test session authority. Wi-Fi and Internet connectivity remain open. App-to-packets test.

Before Enable	Reopened with the connection preserved

What works today

These are separate, documented test checkpoints. They have not all been joined into one complete phone session.

Area	Demonstrated behavior	Evidence
Native apps and themes	Real Messages, Settings and Sounds windows in prepared VMs; live original Omarchy theme changes and permission controls in qualified app sessions.	Messages, Settings brightness, Sounds
Connection ownership	Touch Enable → packets → app close/reopen → explicit Disable and silence through the normal Settings app and Rust services.	Settings connection
Wireless discovery	A native Rust worker discovers the exact test AP through kernel nl80211 in a generic ARM VM, after a genuine refusing RED; the same binary reports unavailable on a non-wireless interface. Association, Internet and Pixel Wi-Fi remain open.	Wireless tracer
ARM app build and partial runtime	Current Settings builds/installs with native Qt 6.12 and matching Rust libraries. A failed ARM trace reaches one Enable touch, a virtual address and one packet; background persistence, reopen and Disable remain open.	ARM build/install, partial failed trace
Audio	Preview Play/Stop, volume and mute verified against measured virtual audio; separate installed ARM service startup and shutdown checks. Physical phone audio remains open.	Preview, live mute
Battery and brightness	Rust services follow real Linux test drivers, including value changes and device loss; installed ARM startup and recovery checkpoints pass.	Battery, brightness
Background services	Seven installed services cold-boot together in a headless ARM development image: battery, brightness, network status and the four-unit audio stack.	Combined ARM image
Local messages	Permission-aware history, revocation, durable storage and clean-reboot persistence; synthetic incoming Binder tests are tracked separately. Carrier SMS remains open.	Installed history, incoming test boundary
Radio, camera and sensors	Rust protocol, ownership and lifecycle components with original-code comparisons and synthetic IPC tests, including actual ARM kernel Binder. Complete IMS, calls and physical capture/sensors remain open.	Radio, camera, sensors

Host component tests, original-code execution, Android reference tests, ARM user-mode emulation, full-system VMs and physical hardware evidence are recorded separately. A passing component or virtual device does not qualify a phone. The integration map links the wider service work; the development handoff records current attempts and next steps, including failed runs.

What remains before a usable phone

• Reliable cold startup into the full Omarchy shell, with trusted lock/unlock, app launching, notifications and background behavior.
• Complete native calls, cellular/IMS and SMS, plus camera, sensors, location, Wi-Fi/Bluetooth and the remaining audio and power paths.
• One installed system with setup, permissions, updates, durable user data and recovery working together.
• Pixel hardware validation: boot and restoration, graphics/display/touch, matched driver interfaces, modem/carrier behavior, physical audio/camera, suspend/wake, thermal behavior and battery life.

The smartphone completion matrix defines the full target. Zero phone models are hardware-qualified. Pixel 10 is the first target; another model needs its own matched assets, backend/profile and device evidence. Portability strategy.

Architecture

The target separates common phone behavior from device-specific operations:

flowchart TD
  Apps[Native apps · Qt/QML presentation] --> Core[Rust services · state, permissions and lifecycle]
  Theme[Omarchy themes and commands] --> Apps
  Core --> Backends[Hardware-specific backends]
  Backends -. device integration pending .-> Kernel[Matched Google Linux kernel and modules]
  Kernel -. hardware validation pending .-> Phone[Pixel 10 hardware and firmware]

Loading

Rust owns phone-service policy, request/model state, deadlines, resource ownership and recovery. Upstream Hyprland, Aquamarine and Qt remain C++ dependencies. The experimental custom renderer is component research; the integrated app path uses the normal upstream compositor. Language and graphics decision.

The Android-derived kernel is an initial hardware-support choice. We retain its Linux drivers and firmware while building native userspace; we are not rewriting the kernel or modem firmware in Rust. Shared services stay portable through separate hardware backends.

Use open-source interfaces first. Where vendor interfaces are closed, use REA and original-code comparisons to recover and validate their contracts. Android and Java components are reference/test infrastructure; the final production architecture targets native Rust services and native apps. Reference environment, native IMS investigation.

Build and contribute

Start with the development handoff, working rules and dependency policy. Small public checks need a recent Rust toolchain and Python, without vendor APKs:

cargo test --locked --manifest-path native-ims/Cargo.toml
cargo clippy --locked --manifest-path native-ims/Cargo.toml --all-targets -- -D warnings
python3 -m unittest discover -s tests -p test_fetch_upstreams.py

Fetch the pinned public Omarchy source with:

python3 tools/fetch_upstreams.py --omarchy

The larger integration suites need a prepared Linux build host, pinned packages, SDKs and VM inputs. See remote development and the relevant evidence report before running them. Build servers are temporary validation capacity, not phone runtime dependencies. A one-command phone installer is not available.

Source	Role
native-lifecycle/, native-process-owner/, native-session-owner/	Shared permissions, process ownership and session composition
native-*-ui/, native-app/	Native app frontends, Rust client engines and shared appearance
native-radio/, native-ims/, other native-* services	Phone protocols, services and backend work
framework/, runtime/	Android/reference components and earlier bridge work
sim/, tools/, docs/	Offline integration, build tooling, decisions and evidence

Proprietary inputs, raw decompilation, credentials, private runtime artifacts, firmware and VM disks are excluded from publication. Public repository audit.

License

Original project code is MIT licensed. See LICENSE and third-party notices. Pokélinux is independent of Omarchy, Arch Linux, Google and other named projects; their code, names and artwork retain their own terms.