Drion · Comparison

Drion vs PenguDroid

PenguDroid and Drion take the same broad approach: no Android system to boot and no container, each app its own Linux process in its own Wayland window, on Android’s own runtime and framework code, with the system services behind them replaced. They differ in how far that goes. PenguDroid answers only some of those services, minimally, and runs apps with your user’s access. Drion implements the system services apps need and puts each app in its own sandbox.

PenguDroid

Minimal system services, and apps with your user’s access. An early experiment.

Drion

Drion’s own system services, and a kernel sandbox for each app.

BothAndroid’s own runtime and framework · one Linux process per app · no Android system to boot, no VM or container
What runs

What stands behind the framework

Both keep the parts an app talks to, Android’s runtime and framework, and replace what a phone runs behind them. The difference is how much of it. PenguDroid, with a small daemon brokering graphics, audio and Android’s inter-process calls, answers minimally for services such as the package and activity managers: its docs list no package manager and no activity lifecycle yet. Drion provides its own implementation of the system services apps need.

PenguDroid
Android app
Android runtime and framework, real AOSP code
PenguDroid shim and daemon, minimal system services
Linux host
Drion
Android app
Android runtime and framework, real AOSP code
Drion system services
Linux host
Isolation

How apps are kept apart

In both, each app is a separate Linux process. PenguDroid runs it with your user’s full access by default: its documentation calls that “the opposite of Android’s process-per-app isolation” and says not to run untrusted APKs. Drion puts a kernel boundary around every app and keeps its own services outside all of them.

PenguDroid
Linux host · your user account
PenguDroid daemon
App A
App B
App C
Your desktop session and files

Each app is its own process with your user’s access. An optional mode blocks 33 system calls, but your files stay open to the app. The network is shared with the host.

Drion
Linux host · your user account
Supervisor
System server
Display
sandbox
App A
sandbox
App B
sandbox
App C

The Linux kernel walls off each app’s processes and private files from the host, other apps and Drion’s own services. The network is shared with the host.

Side by side

The practical differences

Both projects are changing fast. The PenguDroid column describes PenguDroid as of 1 November 2026 and may be out of date; the Drion column describes the closed alpha as of 1 November 2026.

Aspect
PenguDroid
Drion
What runs
Each app as its own Linux process, on Android’s own runtime and framework from Google’s Android 17 image. PenguDroid’s host code stands in for the system server, with minimal answers for the package and activity managers.
Each app as its own Linux process, on Android’s own runtime and framework, served by Drion’s own implementation of the system services.
Isolation
None by default: apps run with your user’s access to your files and session. An optional mode blocks 33 system calls but doesn’t restrict file access, and the project advises against running untrusted APKs.
One kernel sandbox per app process. The system server stays outside every sandbox.
Windows
Each app in its own Wayland window on Linux desktops.
One window per app: resizable on Linux desktops, fullscreen in Gamescope on SteamOS, maximized on Ubuntu Touch.
Getting apps
Run an APK, or a .apkm, .xapk or .apks bundle, from the command line; each app gets its own data folder. There is no package manager yet: the installed package is recreated at each launch.
Add app stores from Drion’s launcher, or install with adb. On Linux desktops, apps appear in the app menu.
Desktop integration
Audio playback through PipeWire, mouse input, and keyboard input with gaps. Recording audio isn’t implemented, and the camera reports none.
App menu, clipboard, audio and notifications on Linux desktops, partly on SteamOS and Ubuntu Touch. Camera and microphone are brokered by the system server.
Google Play
Not covered by its documentation. It makes no claim to pass Play Integrity checks or Google certification.
Optional, installed in a couple of clicks from the store list in Drion’s launcher. Other app stores work too.
Arm-only apps on x86_64
In progress: an arm64 translator built from pinned sources starts running arm64 code, but no arm64-only app has opened yet.
Drion comes with a Native Bridge translator.
Developer tools
No adb service. Its own command line inspects APKs, lists running apps and Android system services.
A standard, authenticated ADB endpoint: unmodified adb and Android test tooling work against it.
Which fits

Different trade-offs

PenguDroid is an open experiment, and you can follow it commit by commit. Drion is built to run apps you install from app stores, each in its own sandbox.

PenguDroid

When you want to follow an open experiment

PenguDroid is open source under Apache-2.0 and changes daily, with its progress logged in the open. It suits developers who want to study or extend it, with apps they trust.

Drion

When you want each app sandboxed

Each app in its own kernel sandbox, with Google Play or other app stores, a standard adb endpoint and arm64 apps on x86_64.