Many of us have heard about or tried out GenyMotion Android Emulator. Did you know running Android applications is also possible on a regular Linux desktop computer without any virtual machines, with modern container technologies?
In this post, I guide you through one good solution I came across with quite a short while ago - Anbox.
Table of Contents
Many of us have handy mobile applications but unfortunately, you can't use them on your desktop computer. Personally, I have several Android applications I wish to run on my Arch Linux laptop because no alternatives are available on other than Android platform.
Finding out solutions
I wanted to avoid overhead of virtual machines, so GenyMotion was not an option for me. Smooth desktop integration was an important priority, as well. After all, I use Linux desktop, and as Android OS is basically a (modified) Linux distribution, so I thought there must be alternative solutions somewhere.
Therefore, I decided to try out Anbox, a LXC (Linux Container) container solution bundling Android OS inside a simple file system tree on a native Linux system. After some time of use, it proved working pretty well although some issues exist.
Basic Anbox structure
Anbox is a Canonical product, and it uses Ubuntu-driven Snap package management system by default. I don't use Snap, so neither does my Anbox installation. Anbox code level architecture is briefly explained in the official Anbox documentation:
When setting up Anbox, two key components should be highlighted: container manager and session manager.
Anbox Container Manager
Anbox Session Manager is basically the Anbox core. It runs LXC containerized Android OS and sits above LXC featured Linux system (userspace + kernel). It handles core Android OS functions, container-specific network connections, device handling and other system level interaction.
Technical details: GitHub: Anbox - src/anbox/container/
Container manager relies on two Linux kernel modules, provided by the project:
ashmem_linux (anonymous shared memory) and
binder_linux (Android system binder) which both are available on GitHub - anbox/anbox-modules repository. Additionally, working LXC installation is required.
The container manager should be run as root user since the process must be granted an ability to create a network interface and interact with Linux kernel. If any way to run the container manager as non-root is possible, let me know.
Privileged and unprivileged mode
It is possible to run container manager in a privileged or an unprivileged container environment. These are LXC terms, and you can read more about them in Arch Wiki - LXC: Privileged containers or unprivileged containers.
I strongly recommended running Anbox Container Manager as an unprivileged LXC process due to security reasons. Anbox security model relies heavily on this configuration.
If you run Anbox Container Manager as a privileged process, you basically run all Android system processes as real root on your Linux computer. By using unprivileged mode, all Android users use a isolated user & group namespace, meaning that even Android root user is mapped away from UID & GID
0. If your Linux system security model works otherwise, using unprivileged mode enhances Anbox security a lot although it is not a fool proof solution.
SECURITY WARNING: Anbox Git Arch Linux AUR package's container manager Systemd service file configuration compromises security as it uses
--privileged parameter. Never do that! I guess this is just a lazy approach to get Anbox to work since configuring unprivileged mode can be pain in the ass for many people, according to many similar issue tickets opened in Anbox GitHub repository (issues).
Android system image and user data
Container manager relies on pre-compiled Android OS system file
android.img. Anbox project provides quite dated image on its website from July 2018 (as of June 2020), based on
Android 7.1.1_r13. The official image has several issues, such as:
Audio latency issue
- Symptoms: when playing video which has an audio track, the video playback interrupts in short intervals. The issue is not fixed in 2018.07.19 image but fix is provided by this Anbox pull request #1034.
Window decoration issue
Known as server-side decoration by the Anbox project.
Symptoms: Android applications do not use your desktop window decoration at all. The issue is not fixed in 2018.07.19 image but fix is provided by this Anbox pull request #1415.
Pause/Resume video & audio issue in default Android gallery application
Symptoms: When playing a video with audio track, the video gets paused if you use any other Android application simultaneously.
This is native Android behavior as in mobile environments, applications may assume they are in background or in foreground, depending on whether the application window has focus or not.
As you can run multiple Android applications side-by-side on a desktop environment, none of Android applications are in foreground or background in Android terms, so videos should not pause based on window focus.
The issue is handled in Android 10 by multi-resume feature. Since 2018.07.19 image file uses
Android 7.1.1 r13as its base, the issue persists.
On the current Android OS image provided by the Anbox project, this issue is most notably noticeable on the default Gallery application (
I have patch-worked the Gallery application so it does not pause video playback when going to background.
Anbox Session Manager
Anbox Session Manager sits between Android applications and the container manager. It handles Android application user-level connections and services and basically makes it possible to run GUI-driven Android applications on a Linux desktop.
Technical details: GitHub: Anbox - src/anbox/cmds/session_manager.cpp
The Anbox container manager must be running before using the session manager. The session manager should be run as regular Linux user.
Compiling Android OS image with patches
As mentioned by people on GitHub, merging code patches require that you compile both Anbox source code and
android.img. Applying patches to the Anbox source code is trivial, but you need to know that the same Anbox source code is used as
vendor code when compiling Android OS image file. Anbox source code basically will locate at
vendor/anbox/ subfolder in Android source code hierarchy. So, in a nutshell, yes, you need to apply same patches twice.
If you want to compile Android OS by yourself, you should follow these guides:
WARNING: Although both guides mention that 100 GiB storage space is enough for AOSP (Android Open Source Project) codebase, it is not - not at all. As of June 2020, the code base has exponentially grown and requires 280 GiB of free space. This does not include space required by a compiled Android code, so reserve 300 GiB at least if you decide to compile the Android OS by yourself. Personally, I grabbed an empty 500 GiB HDD and used that - only for AOSP.
I have git repository anbox-install. Benefits of using installation files of this repository are:
Practically tested configuration to ŕun Anbox in unprivileged mode which vastly improves security aspects of running Android applications. See Privileged and unprivileged mode for details.
Updated Android image, adding audio timing fix and window decoration support
Gallery application no longer pauses videos when running multiple Android applications simultaneosly
Shell-based rough instructions how to compile your own Android image from source if you decide not to trust my image
My files provide more secure way to install Anbox than, for instance, Anbox Git AUR repository files.
For official installation instructions and detailed steps, see Anbox documentation: Install Anbox.
Session manager wrapper script
I provide a simple session manager wrapper script. Reason for this is explained in the file as follows:
#!/bin/env bash This is a simple wrapper workaround. If we launch Anbox session manager before a desktop/Xorg session, the session simply fails to launch, complaining about insufficient drm permissions (permission denied 13) in a Xorg log file. Use this script as start-up program in your desktop session start-up application menu. It ensures that Xorg session starts BEFORE Anbox session manager, and both succeed to launch. [[ $(systemctl is-active anbox-container-manager.service) ]] && systemctl --user start anbox-session-manager
Short-term Anbox experience is somewhat good. Anbox works basically well although some issues exist. It is usable, at least for basic Android applications.
UPDATE: NewPipe no longer works on Anbox (with Android 7.X) due to unimplemented support for required Java class
java.time.temporal.ChronoUnit. See my GitHub repository NewPipe_legacy README file for details.
I haven't used any graphically intensive applications such as games which require advanced OpenGL/Vulkan rendering techniques (and, actually Android 9 is the first Android supporting Vulkan 1.1 API).
Application installation is possible with
adb. Simply use command
adb install -r <apk-package-file> command on your main Linux system.
If you need to download Android application APKs from Google Play Store, I recommend Google Play Downloader via Command Line (gplaycli). Otherwise, prefer F-Droid.
Running applications is very simple: each time you install a new Android application, Anbox creates a new
desktop file (location:
$HOME/.local/share/applications/anbox/) which links to your desktop. Application category is not recognized by default FreeDesktop.org configuration, so your system may drop Android application shortcuts into category
lost+found. Otherwise, no complaints.
At least the following features work out-of-the-box:
Video & audio playback (with audio timing + gallery app fixes)
App menu navigation, swipe update functions (with mouse), typing text, controlling window elements
GPS/GNSS location information (Anbox seems to lack support, see this GitHub issue ticket (Mock Location on Anbox not working))
Google applications (GApps)
Games or any graphically intensive applications
Applications may become unresponsive
This happens on some circumstances. Running couple of Android applications simultaneously performs well, but opening, let me say, 7 applications may have performance impact and application unresponsiveness. Using newer Android version in the Android image
android.img may help but it is likely that Anbox codebase would require improvements, too.
Application unresponsiveness may also happen if you let your Android application be passively opened for a long time. The only way to close unresponsive Android applications is either killing them with Linux process management tools (
killall and friends) or if possible, using Android
Settings Manager provided by the Android image.
Missing ability to control background activity
One thing I noticed when using NewPipe was inability to control background player. By referring to background, I mean all application activities (such as badges) you can pop out from application task bar on Android tablet or mobile phone. This is frustating since many application activities rely on properly controllable background.
In my case, I could start a new background audio playback on NewPipe but I could not stop, pause or close it in a normal way. You can close such background activity by closing the whole application process (closing just application window is not enough), meaning that you need to use either Android Settings Manager or main Linux system process management tools to kill the PID (process ID).
To overcome the issue, I slightly modified NewPipe application source code so that the background player is accessible directly via NewPipe without relying on native Android background activity features.
Black application window on multi-monitor setup
Occasionally, if Anbox window is spawned to the primary monitor, it renders mostly as black on other screens. This does not happen if the window is initially spawned on the second or the third monitor. Reason for this weird rendering bug is unknown.
Reading Android log data
In a case of failure or any other unwanted behavior, I recommend using native Android log reading capabilities. Use
adb shell command to access Android shell, and further, use
logcat command to get output of Android process logs. The data may reveal issues or give the right direction to you.
For use convenience, I use two shell command aliases for restarting and killing Anbox processes. I have put them into my
alias anbox-restart='sudo systemctl restart anbox-container-manager.service && sleep 2 && systemctl --user restart anbox-session-manager' alias anbox-kill='sudo kill -9 $(pidof anbox) ; sudo systemctl stop anbox-container-manager.service' # This one may get stuck during first command execution #alias anbox-kill='systemctl --user stop anbox-session-manager && sudo kill -9 $(pidof anbox) && sudo systemctl stop anbox-container-manager.service'
I do not recommend starting the Anbox processes and launching Android applications from your desktop application menu until commands in
anbox-restart alias have been executed.
Enforcing a local DNS server
I have a local DNS server on my Anbox laptop. To enforce it for Anbox, see git/anbox-install - enforced DNS for details.
Anbox proves that seamlessly running Android applications is possible on Linux desktop. Desktop integration is in good shape, and Android applications work pretty well. Some issues exist but if you can tolerate them, go ahead and try Anbox! At least if you wish to run Android applications which haven't equivalent or good desktop alternatives available.