Drion runs unmodified Android apps on Linux as ordinary processes. Each app gets its own window and uses the host’s audio, network and GPU; on a Linux desktop it also sits next to your other programs and shares their clipboard and notifications. Apps can be inspected and stopped with standard Linux tools, and it all runs under your user account.
Apps run as ordinary Linux processes, next to your other programs.
Apps are not rewritten, patched or relinked.
Binder works without the Android kernel driver.
Enforced by the Linux kernel, before any app code runs.
An Android app doesn’t need a whole Android operating system. It needs the Android runtime, Android’s standard libraries (the framework), and system services that answer its requests.
Drion is a small set of cooperating processes with separate jobs and separate authority. Permissions and other decisions are made outside the apps.
Each running app process gets its own sandbox: the Android runtime with the app loaded.
Android’s system side: which app is in front, installed packages, permissions, notifications, alarms and background jobs.
Helper processes: ADB, storage, web content, media
Puts app frames on screen and sends keyboard, mouse, touch and gamepad input back.
Starts the system server and restarts it if it fails, opens a display window for each app, and installs apps. Apps never talk to it.
Host adapters are the parts of Drion that talk to one particular host: its notification service, clipboard, audio system, compositor. Every arrow from Drion’s services into the Linux host goes through one, and each platform gets its own set.
Permissions, the foreground app and installed packages are decided by the system server, which runs outside every sandbox. Apps can only ask.
The receiving process asks the kernel who is calling. Nothing an app claims about itself is trusted.
A crashing app ends its own process. The system server keeps its state and the supervisor restarts what must restart.
Before any app code runs, each app process gets its own Linux user, mount, PID and IPC namespaces, then is locked down further. Every layer is enforced by the kernel or by a Drion process outside the sandbox.
/systemread-only/data/user/0/‹app›private/storage/emulated/0shared, as on a phone/devminimal/proc lists only the app’s own processesnot visiblenot mountednot visibleonly through the system serverbrokerednot presentnot reachableThe app cannot see or signal host programs or other apps. Some apps deliberately probe and kill other processes; under your account that could end your session.
Read-only system files, its own private data and shared storage. Your home folder is not mounted in.
Basic pseudo-devices, private pseudo-terminals, and only the GPU and video-decoding devices that graphics and video need.
no_new_privs blocks setuid. As on Android, a system-call filter refuses mounting, namespaces, kernel modules and kernel administration. Apps get an ordinary error rather than a crash.
Files and sockets held open by the processes that launch it are closed before it starts.
Release builds refuse the development switches. If the kernel can’t build the sandbox, the app doesn’t start. On Ubuntu Touch, AppArmor confinement applies as well.
When an app connects, the system server asks the kernel which process is calling and accepts only app runtimes it started itself. Identities claimed inside requests are ignored, and no passwords or tokens are involved.
Work as on Android: the app asks, you answer a prompt, the system server stores the answer.
Brokered. The app never sees the host camera or audio connections.
Checked before any host data is read. Approximate-only apps get an approximate position.
Drawing over other apps, reading all files or installing apps needs your approval in a Drion dialog.
An app sees its own data, never another app’s.
Except each app’s Android/data and Android/obb folders.
Account credentials, keystore contents and lock settings.
Off by default. Machine-bound key, not hardware-backed.
APK signatures are checked and recorded at install.
Only trusted keys; a new key is never trusted automatically.
Apps are isolated from the host, not the other way round. Drion’s data lives in your account, like your other files.
Apps use the host’s network directly, including services that listen only locally. Drion does not filter app traffic.
Drion has no lock screen of its own. Protect app data with your login and disk encryption.
Keys are not kept in hardware such as a TPM, and device attestation fails.
The Android-facing code is the same everywhere and is only built for different CPUs. What changes is a set of host adapters that connect the system services to each host’s display, input and hardware.
Android runtime · framework · system server · sandbox
Drion exposes a standard, authenticated ADB endpoint, so unmodified adb and Android test tooling work against it.
# the same commands you use with a phone $ adb install app.apk $ adb shell $ adb logcat
Install APK, APKS, XAPK and APKM files from the launcher or the drion command-line tool.
App stores running inside Drion can install and update other apps.
Subsets of Android’s Compatibility Test Suite run on demand. This is not certification.
Per-session rotated logs, crashes with native backtraces, and a monitor for frame rate, CPU and memory.
Email us to join the closed alpha. There is no public release yet.