Drion runs each Android app as its own sandboxed Linux process, with no Android system or virtual machine underneath. These pages put it side by side with other ways to run Android apps on Linux: a container, virtual machines, a translation layer and a Linux phone OS’s own Android runtime. What each page says about another project is checked against that project’s own documentation, source or release notes, listed on the page.
These projects were built for different jobs: the Android Emulator and Genymotion Desktop for testing apps during development, AppSupport as Sailfish OS’s own Android runtime. The table shows how each one works, not which is best. Each column sums up its full comparison.
| Aspect | Drion Current | WaydroidVersion 1.6.3 | Android EmulatorVersion 37.2.12 | Genymotion DesktopVersion 3.11.0 | Android Translation LayerCommit f9e2280c | Sailfish OS AppSupportSailfish OS 5.2.0.18 |
|---|---|---|---|---|---|---|
| What runs | Each app as its own Linux process, served by Drion’s system services. | A complete Android 13 system, based on LineageOS, in an LXC container. | A complete Android system image, its own kernel included, in a QEMU virtual machine. | A complete Android system image in a virtual machine, QEMU with KVM by default. | Each app as its own Linux process, on ATL’s own implementation of Android’s app APIs. | An Android 13 or 15 system image in an LXC container. |
| Isolation | One kernel sandbox per app process. The system server stays outside every sandbox. | One container for the whole system. Android’s own app sandbox separates apps inside it. | One virtual machine for the whole device. Android’s own sandbox separates apps inside it. | One virtual machine for the whole device. Android’s own sandbox separates apps inside it. | None yet: apps run with your user’s access, and sandboxing is on the roadmap. Flatpak-packaged apps get Flatpak’s sandbox. | One container for the whole Android system. Android’s own permissions apply to each app inside it. |
| Starting the first app | No Android system to boot. An app starts like any other program. | Android boots first. Later apps start inside the running system. | The virtual device cold-boots, or resumes from a Quick Boot snapshot, before your app starts. | The virtual device boots Android before your app starts. Quick boot is off by default and not in the free edition. | No Android system to boot. Each app starts as its own Linux process. | AppSupport starts with the phone, or, if you turn that off, with the first Android app you open. |
| Windows | One window per app: maximized in Lomiri on Ubuntu Touch, resizable on Linux desktops, fullscreen in Gamescope on SteamOS. | The full Android interface in one window by default, or one window per app in multi-window mode. | The whole device screen, in Android Studio or in a separate window. | The whole device screen, in a window, full screen or inside a device skin. | Each app in its own GTK4 window, on Wayland or X11. | Apps open like Sailfish apps, with covers on the home screen. |
| Google Play | Optional, installed in a couple of clicks from the store list in Drion’s launcher. Other app stores work too. | Optional image with Google apps. | Separate system images with the Play Store. They don’t allow root access. | Not included. A built-in widget downloads Open GApps and flashes it into the device. | No Google Play Services. Built-in stubs stand in for common calls, and microG can be added. | No Play Store app, and Jolla advises against Google Play Services. Apps from Google Play install through Aurora Store; Sailfish OS 5.2 offers microG. |
| Arm-only apps on x86_64 | Drion comes with a Native Bridge translator. | Not in the official images. Added with third-party community scripts. | Arm translation in the x86_64 Google APIs and Play images since Android 11, for development and debugging only. | Not supported on PCs. Some 32-bit Arm apps run after you flash Arm translation tools, which Genymobile can’t distribute. | A separate, optional add-on based on QEMU, built and set up by hand. | Not covered |
Each column was checked against the version under its name; its full comparison says when, and lists its sources. “Not covered” marks a point the project’s own sources don’t settle.
Email us to join the closed alpha.