Actinis Drion
Coming soon

Android apps, Linux-shaped.

A Wine-like Android compatibility platform. Drion preserves the contracts Android apps expect and replaces system-side behavior with Rust and hosted ART — so Android apps run on Linux with real host integration, not beside it.

App execution · traditional vs Drion
Traditional (Waydroid / emulator)
Android app
Android framework
Android kernel / container
Host Linux
Drion
Android app
Drion (ART + contracts)
Host Linux
Host integration
  • Audio devices
  • Webcams
  • Sensors, location
  • Clipboard, notifications
What it is
// drion.md

Drion is a Wine-like compatibility platform for Android. Apps see the same contracts they expect — Binder, Activity, Service, ContentProvider, package metadata, intents, notifications — and we replace the system-side implementation behind those contracts in Rust.

Apps load and run against real Android runtime pieces: a hosted ART executes the APK, bionic-linker behavior is preserved, framework client-side code is kept close to real Android. A shared drion-system-server owns lifecycle, policy, and package state; a launcher daemon supervises sessions; a display-sink process handles local windows and input on Wayland. The sink interface is pluggable, so future host platforms don't require a rewrite.

Containerless by default — apps run as per-app sandboxed Linux processes (user + mount namespaces, seccomp-ready), the same kernel primitives Flatpak and rootless Podman use. Containerized when you want it — the same core also runs under Docker Compose for web deployment. The deployment profile changes; the compatibility model doesn't.

Host integration is a first-class feature. Audio devices, webcams, sensors, location, clipboard, and notifications pass through to the host instead of being stubbed out. Android apps integrate with the desktop, not beside it.

Design principles

Preserve contracts. Replace implementations

01 · Wine-like

The compatibility boundary is system-side

App-process side stays close to real Android — hosted ART, bionic-linker behavior, framework client code. System-side services, providers, and policy are Drion's. Apps see Android; the OS is Linux.

A long-lived session daemon coordinates processes, lifecycle, and cross-app routing — in the architecture docs' own words, the Android compatibility equivalent of wineserver.

02 · Chimera bridge

arm64 apps on x86_64 hosts

On x86_64 hosts, Drion can pair with Chimera so arm64-only Android apps run through the Native Bridge translator. Drion owns Android contracts, lifecycle, and host integration; Chimera handles the CPU-architecture bridge.

03 · Containerless

A sandboxed process, not a guest OS

Drion runs Android apps as per-app sandboxed Linux processes: user and mount namespaces, Android-shaped filesystem view, seccomp-ready. Same sandboxing foundation as Flatpak — no guest kernel, no Android system image, no VM. A Docker Compose profile is available for web deployment; nothing else requires it.

04 · Host integration

Audio, webcam, sensors — pass through

Device-facing capabilities are pluggable adapters. The default desktop profile passes through host audio, webcams, location, clipboard, and notifications. Headless, host-local, and remote profiles are all selectable without forking the platform.

05 · System services, reimplemented

Most of Android, rebuilt behind Android's contracts

drion-system-server is a ground-up reimplementation of the Android services apps actually depend on — activity and task management, window management, service lifecycle, package state, permissions, AppOps. Contracts stay Android-shaped; the code behind them is ours. Trusted caller identity is preserved across Binder and Unix-socket IPC, enforced by the kernel (SO_PEERCRED + per-app user namespace).

06 · Deployment boundaries

One compatibility core, adapters per deployment

Drion's desktop, headless, and Docker Compose deployment profiles share one compatibility core. Customer-specific integrations attach through generic IPC and adapter boundaries, so deployment work stays separate from the Android contracts apps depend on.

Who it's for

Android apps, anywhere Linux runs.

01

Steam Deck & Steam Machine

Play Android games and use Android apps on Steam Deck, Steam Machine, and other SteamOS devices with less overhead than Waydroid and 1-click persistent installation.

02

Linux phones

Mobile Linux distributions that want Android app compatibility without shipping a second OS. Drion keeps the host kernel and the host UI; Android apps are just processes.

03

Linux desktops

Bring the Android app catalogue to GNOME, KDE, and Sway with real host integration: Wayland-native windows, host audio, host clipboard, host notifications.

04

Embedded & automotive

Linux-based embedded surfaces that already ship Android apps — automotive head units, industrial HMIs, smart displays — where device-integration adapters can be selected per deployment profile.

05

CI & instrumented tests

Run Android instrumented test suites in CI without booting a full emulator. Apps skip the emulator boot, share the host kernel, and scale horizontally on ordinary build agents.

06

Researchers & forensics

Instrument, trace, and sandbox Android apps with ordinary Linux tooling: strace, perf, seccomp, eBPF. An Android app as a Linux process is a far better research subject than an Android app in an emulator.

Development status

Active development. No public release yet.

Drion is being actively built, but it is not available as a public release today. Join the waitlist for release updates.

// not released yet
Waitlist

Know when Drion ships

We'll email when there is a meaningful product update or preview path. No drip campaigns.