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.
The installed ARM VM flow now reaches genuine Permissions Allow, Settings Enable, a UDP roundtrip, normal Settings close, reopen on the same service worker, a second UDP roundtrip and explicit Disable with independent disconnected readback. It uses a fixed open access point over simulated Wi-Fi. Latest partial milestone.
The full run still fails: its original clock cannot admit the final quiet check, and guest diagnostic cleanup hits open-file exhaustion. Quiet, complete guest closure and persistence across two boots remain unqualified. Current status and retained failures.
Separately, a headless ARM service test passes connection, packet exchange across actual client close/reopen, explicit Disconnect and quiet checks. Its controlled simulated-radio fixture qualifies the service lifecycle separately from the normal installed GUI and consent flow. Headless service evidence.
The radio-observation change passes separate ARM controls and public build/image checks. These remain distinct from the incomplete installed flow. Diagnostic and deferral scope.
Settings reopened while the connection remained enabled, before the second packet and Disable:
This unaltered 1080 × 2424 capture is from a generic ARM VM configured for the Pixel 10 profile. The partial run fails final quiet admission and guest diagnostic closure. Phone hardware and app display scaling remain unverified.
Earlier consent milestone: these two raw ARM frames show the Allow status change.
| Before Allow | After Allow |
|---|---|
 |
 |
These unaltered captures come from an ARM VM configured for the 1080 × 2424 Pixel 10 profile. App display scaling and phone hardware remain unverified. These frames retain the earlier post-Allow deadline miss. Later runs pass the timed Allow check, normal close and Settings layout. A later run confirms one connection, packet roundtrip and retention after close. Cold 26 also reaches reopen, packet 2 and Disable; final quiet, complete closure and the two-boot flow remain unqualified. Milestone and limits.
The earlier captures below are real, unedited x86 VM captures at the Pixel 10 display profile: 1080 × 2424 pixels, 422 PPI and 420 logical density. Some captures retain upstream development notices.
The latest viewer test drives genuine Omarchy: open Sounds, close it with Super+W, reopen it, receive the final image and shut down normally. This automated VM path passes; a user-launchable preview is next. Permission remains withheld in this capture, so Play stays disabled.
A later normal-entry preview opens Sounds through an external automated client without the capture wrapper, then shuts down normally on disconnect. A Harbour launch command and connection recipe are now available; human SSH/VNC access remains unverified.
Native permission controls now complete a real VM sequence: allow Sounds, play a tone, revoke permission to stop it, then allow again without restarting playback. The phone window profile keeps each focused app usable below the Omarchy bar. Independent audio capture measures tone followed by silence. Both apps close normally in two runs. A later repeat observes no playback producer and stops before the tone check; its cause remains unknown. Play now accepts a tap during a background status refresh. A fresh complete run now passes the updated app's permission/audio sequence, viewer final frame and EOF, and full VM/container shutdown. The prior run's obsolete test-count assertion is repaired; its original failed result remains separate. This is VM evidence, not physical-phone audio. The frozen screenshot above predates these controls.
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. This graphical checkpoint uses a virtual link. App-to-packets test.
| Before Enable | Reopened with the connection preserved |
|---|---|
 |
 |
The Rust Wi-Fi service now keeps a connection alive across test-app closure and reopening in an ARM Linux VM. The same app SDK connects once, independent packet probes succeed before and after reopening, and explicit Disconnect removes the address and association and passes quiet checks. Full process and VM cleanup passes too. This uses simulated radios, an open test AP and fixed IPv4; Wi-Fi network selection, WPA, DHCP/DNS, Internet and Pixel hardware remain open. The screenshots above show the earlier virtual-link UI, not this wireless run. Persistent wireless evidence. Two later diagnostic-cohort ARM runs pass persistence and AP-loss retirement, including actual SDK unavailable state and complete owned shutdown. The earlier app-client failures remain unexplained; added test diagnostics are not a proven repair. Current results.
Two ARM VM runs completed the normal Settings wireless sequence: Enable, packets, normal close/reopen, another packet, then Disable and silence. Full acceptance remains incomplete. Later checks narrowed startup-process ownership to one unattributed child; another run lost radio observation during reopening. The VMs shut down and were removed. The next full acceptance targets installed boot and normal permission consent. These runs use simulated radios, an open AP, fixed IPv4 and authored test authority. Functional results and remaining gates.
Exact native 1080 × 2424 capture in the fallback theme, using the selected Pixel 10 display profile (422 PPI, 420 logical density). This is a simulated ARM window, without physical-phone or complete-session qualification.
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 |
| Viewer controls | Seven mouse/keyboard actions open, close and reopen Sounds; native final image and normal VM shutdown pass. Human connection workflow remains open. | Viewer test |
| App lifecycle | Genuine Omarchy menu → Sounds → Super+W close → fresh menu reopen → normal shutdown, with the same Rust session owner and permission withheld. | Close/reopen test |
| Connection ownership | Touch Enable → packets → app close/reopen → explicit Disable and silence through the normal Settings app and Rust services. | Settings connection |
| Session recovery | The same Sounds window survives a compositor pause; fresh state returns about 55 ms after resume, followed by measured playback and permission-revoke silence. Earlier audio failures remain under investigation. | Recovery checks |
| Connection reliability | Controlled idle delays no longer stop the connection worker; overdue replies are still rejected. Host process tests only. | Main idle polling |
| Wireless | The Rust service passes headless persistence with full cleanup. Normal Settings also passes Enable, packets, close/reopen and Disable/quiet in an ARM radio simulation; the guest-closure criterion remains open. Wi-Fi selection, WPA, DHCP/DNS and Pixel hardware remain open. | Normal Settings result, persistent service |
| ARM app build and functional runtime | Normal Settings builds/installs with native Qt 6.12 and matching Rust libraries. The wireless window sequence passes; full guest closure and installed session composition remain open. Earlier failed virtual-link traces are preserved. | ARM build/install, current wireless result |
| 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 |
A controlled audio startup test now survives a delayed backend within the original Play time limit. Losing session authority or reaching the app timeout still cancels it without retry. This is a host integration result; repeatable graphical playback and phone audio remain open.
The current Messages background owner now passes one fresh ARM/PID1 cold boot, exact private history reads and normal Stop. A second new boot and graphical session remain open.
An earlier cold x86 recovery trace starts genuine Omarchy and the Rust-backed Sounds window, recovers from a compositor pause without restarting the app, then measures 50% playback on the virtual speaker and silence after an operator permission revoke. Normal shutdown also passes at the Pixel 10 display profile. This run adds diagnostics; earlier audio failures remain unresolved, and repeatability is not established. Interactive use and phone hardware remain open. Cold trace and evidence.
The genuine Omarchy menu now launches Sounds through three real taps and the Rust-owned app service. Window, focus and permission-withheld silence checks pass; later playback in that run still fails. A later complete app-lifecycle run now passes menu launch, standard close, fresh reopen and normal shutdown. Both app instances retain the Pixel 10 display profile and remain silent without permission.
The later viewer run, pictured above, carries this loop through actual viewer input and final framebuffer receipt.
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.
- 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.
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]
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.
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.pyFetch the pinned public Omarchy source with:
python3 tools/fetch_upstreams.py --omarchyThe 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.
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.