Drion · Comparison

Drion vs Android Translation Layer

Both run Android apps on Linux without booting an Android system: each app is its own Linux process, in its own window. They differ in which part of Android they rebuild. Android Translation Layer (ATL) reimplements the Android APIs that apps call, on top of desktop Linux libraries such as GTK4. Drion keeps Android’s own framework code in the app and replaces the system services behind it.

Updated

ATL is evolving quickly and has no versioned releases. This page describes it as of , so some of it, such as what ATL can sandbox or support, may have changed since. Seen something out of date? Tell us at contact@actinis.io.

ATL

Android’s app APIs, rebuilt on GTK4 and desktop Linux libraries.

Drion

Android’s own framework code, with Drion’s system services behind it.

BothNo Android system to boot · one Linux process per app · no virtual machine
What runs

Which part each one replaces

ATL makes its cut directly between the app and Android’s framework: the APIs an app calls are ATL’s own code, with some parts copied from Android’s source, and they draw with GTK4. Drion keeps the parts an app talks to, the runtime and Android’s framework, and replaces the system services underneath with its own.

Android Translation Layer
Android app
Android app APIs, reimplemented by ATL
Desktop libraries: GTK4, ALSA, portals
Linux host
Drion
Android app, unmodified
Android framework, real AOSP code
Drion system services
Linux host
Isolation

How apps are kept apart

In both, each app is a separate Linux process. ATL runs it with your user’s full access for now: its source notes that “the app can access anything it wants”, and sandboxing is on its roadmap. Drion puts a kernel boundary around every app and keeps its own services outside all of them.

Android Translation Layer
Linux host · your user account
App A
App B
App C
Your desktop session and files

Each app is its own process with your user’s access. Apps packaged as Flatpaks get Flatpak’s sandbox instead.

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 ATL column describes ATL as of 5 October 2026 and may be out of date; the Drion column describes the closed alpha as of 9 October 2026.

Aspect
Android Translation Layer
Drion
What runs
Each app as its own Linux process, on ATL’s own implementation of Android’s app APIs and a standalone ART runtime.
Each app as its own Linux process, on Android’s own framework code, served by Drion’s system services.
Isolation
None yet: apps run with your user’s access, and sandboxing is on the roadmap. Apps packaged as Flatpaks get Flatpak’s sandbox.
One kernel sandbox per app process. The system server stays outside every sandbox.
Windows
Each app in its own GTK4 window, on Wayland or X11.
One window per app. Fullscreen in Gamescope on SteamOS, maximized on Ubuntu Touch.
Getting apps
Run an APK file from the command line. An install option adds it to the desktop’s app menu.
Add app stores from Drion’s launcher, or install with adb. On Linux desktops, apps appear in the app menu.
Desktop integration
Notifications, audio playback, and copying text out of apps; apps can’t read the clipboard. Microphone and location stay off unless turned on with environment variables. Camera isn’t implemented.
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
No Google Play Services. Built-in stubs stand in for common calls, and microG can be added.
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
A separate, optional add-on based on QEMU, built and set up by hand.
Drion comes with a Native Bridge translator.
Developer tools
A Java debugger can attach directly. adb works through a separate add-on.
A standard, authenticated ADB endpoint: unmodified adb and Android test tooling work against it.
Which fits

Different trade-offs

ATL is free software that grows app by app, and you can help it along. Drion runs apps on Android’s own framework code, each in its own sandbox.

Android Translation Layer

When you want free software you can extend

ATL is open source and developed in the open. It suits the apps its developers have already brought up, and people willing to add the Android APIs an app is missing.

Drion

When you want each app sandboxed

Unmodified apps on Android’s own framework code, each in its own kernel sandbox, with Google Play or other app stores.

Architecture · diagramsHow Drion worksProcesses, the per-app sandbox, permissions and platforms, with diagrams.
More comparisons
ContainerDrion vs WaydroidArchitecture, isolation, root and desktop integration, side by side.Virtual machineDrion vs the Android EmulatorA virtual device, or apps as Linux processes: startup, windows, networking and arm64 apps.Commercial virtual machineDrion vs Genymotion DesktopVirtual test devices, or apps as Linux processes: Arm-only apps, Google Play and licences.Linux phone OSDrion vs Sailfish OS AppSupportJolla’s Android container, or apps as Linux processes: devices, isolation and Google services.
Closed alpha

Try Drion on Linux desktops and Ubuntu Touch

Email us to join the closed alpha.

alpha@actinis.io Back to Drion