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 · 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.

03 · 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.

04 · 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).

05 · Debuggable from day one

Session-keyed diagnostics across every layer

Every session gets a unique ID propagated into every log line, crash dump, frame snapshot, and event-timeline entry — Rust, C++, and Java layers share one format. Hand an AI agent the session ID; the whole diagnostics bundle is one read. Release builds stay silent by default; dev builds are verbose with zero configuration.

06 · Open core, clean commercial boundary

EUPL-1.2 core, proprietary extensions stay out of it

The Drion core is useful on its own — desktop, headless, and Docker Compose web deployments all work on the OSS side. Proprietary extensions, when Actinis ships them, attach through generic IPC interfaces; the open-source core never carries proprietary names or protocol secrets.

Who it's for

Android apps, anywhere Linux runs.

01

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.

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

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.

04

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.

05

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.

Open source

Readable. Auditable. Yours to run

Drion ships under the European Union Public Licence 1.2 — compatible with GPLv3, drafted by the European Commission, and legally sound in every EU member state.

// public repos coming at launch
Waitlist

Know when Drion ships

We'll email once — when the code is public. No drip campaigns.