DroidDesk: a Linux desktop on an Android phone, two ways

What DroidDesk actually replaces

The usual way to run Linux software on a phone is a remote shell into a server, or a terminal emulator with no GUI at all. DroidDesk targets the gap between those: a full desktop environment with a window manager, an application menu, and GUI programs running locally on the phone's own kernel. The README frames it as "Not a terminal. Not an emulator. A complete desktop environment with direct kernel access."

The audience is narrow but real. You need an ARM64 Android phone, a willingness to sideload APKs and run shell scripts, and a reason to want LibreOffice, VS Code or Wireshark on a device you already carry. The README's list of confirmed-working software includes LibreOffice, VS Code with Python and extensions, Blender (described as laggy on mobile hardware but functional), Wireshark, Metasploit, and offline LLM inference. That list is the project's own claim, not an independent benchmark.

The project is GPL-3.0 and states plainly that it is independent, incorporating modified Termux:X11 components, and not affiliated with or endorsed by Termux, Termux:X11, TUR, Canonical or Ubuntu. That disclaimer matters because the name sounds like an official Ubuntu product and it is not one.

Two architectures under one name

DroidDesk is really two delivery paths sharing a name and a rendering stack. The first is a shell script, termux-linux-setup.sh, that runs inside an ordinary Termux installation you install yourself. It adds the X11 and TUR repositories, installs one of four desktop environments, configures GPU acceleration with Turnip for Adreno chips and a Zink fallback otherwise, and sets up a Proot container for packages TUR does not carry. Rendering goes through the separate Termux-X11 app.

The second path is the standalone Android application. It bundles an ARM64 Termux bootstrap, extracts it, configures a private package prefix, and installs the desktop automatically, so you do not need Termux at all. The app renders through an embedded Termux:X11 server running in its own Android process, and the README is explicit that the app does not use VNC. On rooted phones it runs the Ubuntu filesystem through chroot. On non-rooted phones it runs an app-private native Termux userspace and pulls desktop packages from the X11 and TUR repositories, and the README states PRoot is not used in that mode.

That last detail is the most interesting design choice in the repository. PRoot is the common trick for unprivileged Linux on Android, but it intercepts system calls and costs performance. DroidDesk's app mode avoids it for the non-root path and reserves chroot for rooted devices. The script path still uses a Proot container, so the two modes are not equivalent.

Installing DroidDesk through Termux

The script route assumes you already have Termux. The README is blunt about the source: install it from F-Droid, and do not use the Play Store version, which it calls outdated and non-functional. Termux-X11 is a separate APK from the upstream nightly release page. Both are prerequisites before any DroidDesk code runs.

With Termux open, the setup script is fetched and executed directly:

curl -sL https://raw.githubusercontent.com/orailnoor/DroidDesk/main/termux-linux-setup.sh -o setup.sh
bash setup.sh

The README lists nine things that script does in order: updating Termux packages, adding the X11 and TUR repositories, installing your chosen desktop, setting up GPU acceleration, installing Firefox, Git, Python and core tools, creating the Proot container, creating the app bridge for menu syncing, applying a dark theme, and optionally configuring VNC. Expect a long run; the package set is a desktop environment plus a container.

When it finishes, start the desktop and open the Termux-X11 app:

bash ~/start-x11.sh

For software TUR does not package, you enter the container, install with apt, exit, and resync the menu:

bash ~/start-proot.sh
apt install wireshark
exit
bash ~/proot-menu-sync.sh

The README says the app then appears in your desktop menu automatically. The commands reference also lists bash ~/start-vnc.sh and bash ~/stop-linux.sh for VNC sessions and for stopping everything.

Monitor output is the weak point

A desktop on a phone screen is usable but cramped. The README offers two ways out. Option A is USB-C display output through a USB-C to HDMI adapter, which it describes as simply working if your phone supports it. Option B exists because most mid-range phones do not: the phone's USB-C port is USB 2.0 and carries no video signal.

For those phones the project documents a Raspberry Pi Zero 2W bridge. The Pi runs Raspberry Pi OS, connects to the phone over USB tethering, detects the phone's IP automatically, and opens a VNC viewer fullscreen on the monitor. The parts list is specific: Pi Zero 2W, micro USB to USB-C cable, USB-C hub, micro HDMI to HDMI adapter, SD card, and a wireless keyboard and mouse. On the Pi you install realvnc-vnc-viewer and copy pi-launch_phone.sh across:

sudo apt update
sudo apt install realvnc-vnc-viewer
curl -sL https://raw.githubusercontent.com/orailnoor/DroidDesk/main/pi-launch_phone.sh -o ~/pi-launch_phone.sh
chmod +x ~/pi-launch_phone.sh

Then you enable USB tethering on the phone, run bash ~/start-vnc.sh in Termux, and run bash ~/pi-launch_phone.sh on the Pi. The README also gives a crontab line, @reboot sleep 15 && /home/pi/pi-launch_phone.sh, for auto-connect on boot.

This is a genuine limitation rather than a footnote. If your phone lacks video output, the monitor experience requires a second computer, a VNC hop, and the latency that comes with it. And note the asymmetry: the standalone app renders through its embedded X11 server and the README says it does not use VNC, while the Pi bridge depends on the VNC path from the script setup. The two halves of the project do not meet cleanly here.

Process killing and the rooted versus non-rooted split

The README carries a warning that on some Android versions, specifically MIUI, One UI and stock Android 13+, the system may kill Termux background processes and drop the desktop session. The documented mitigation is disabling child process restrictions in Developer Options. This is not a DroidDesk bug so much as an Android memory-management behaviour, but it lands on the user either way, and it is the kind of thing that makes a session die mid-edit.

The rooted and non-rooted app modes also differ in ways the README only sketches. Rooted phones run the Ubuntu filesystem through chroot, which is the conventional approach and gives a standard filesystem layout. Non-rooted phones get an app-private native Termux userspace with packages from the X11 and TUR repositories. The README does not document which packages exist in each mode, how to migrate a Proot container built by the script into the app's userspace, or what happens to your data if you switch paths. If you start with the script and later install the app, treat them as separate environments until the repository says otherwise.

There is also a hardware ceiling. Everything is ARM64, and the README's own note on Blender says it is laggy on mobile hardware. Repository files include fetch_deps.sh and a LICENSES directory alongside COMPLIANCE.md and THIRD_PARTY_NOTICES.md, which suggests the licensing paperwork is taken seriously, but the README does not document rollback or uninstall for either mode.

How DroidDesk differs from Andronix and UserLAnd

The obvious comparison is with Andronix and UserLAnd, which also put Linux distributions on Android. The difference is where the desktop lives. Those tools generally give you a distribution inside a container and then expect you to attach a display through VNC or an X server app you install separately. DroidDesk's standalone app bundles the Termux userspace, the package prefix and the X11 server into one Android process, so the desktop and the display server ship together and there is no VNC step in that mode.

The second difference is the package strategy. DroidDesk splits software between TUR, which provides GUI applications built for Termux, and a Proot container for everything else. Andronix and UserLAnd lean harder on the distribution's own package manager from the start. DroidDesk's menu sync script is the concession that this split creates friction: you install inside the container, exit, and resync so the launcher appears outside it. That is a workaround, and the README presents it as a feature rather than acknowledging the seam.

If your workload is a single CLI tool or a headless service, none of this matters and a plain Termux install plus ssh is lighter. DroidDesk is for people who specifically want windows, a menu, and GUI applications on the phone itself.

Licence, upgrade cost and what to check before adopting

DroidDesk is GPL-3.0. It incorporates modified Termux:X11 components, which is why the repository carries NOTICE.md, THIRD_PARTY_NOTICES.md, COMPLIANCE.md and a LICENSES directory. If you redistribute the app or a modified build, the GPL-3.0 obligations apply to your distribution, and the third-party notices exist to tell you which upstream projects are involved. This is not legal advice; read LICENSE and the notices files yourself before shipping anything.

Upgrade cost is the practical question. The script path installs packages from TUR and the X11 repositories and keeps a Proot container alongside them, so a fresh run of termux-linux-setup.sh is the upgrade path the README describes, and it is also the path that can overwrite desktop choices. The app path depends on sideloading a new APK from the Releases tab; the only release listed is v1.0.0 from 2026-07-11. The last push to the repository was on 2026-08-05, so the codebase has moved since that release.

Before adopting, verify three things. That your phone is ARM64. That Termux comes from F-Droid, not the Play Store. And that your OEM's background process policy will let the session survive, since the README's own warning names MIUI, One UI and stock Android 13+ as the cases where it may not. APP_TROUBLESHOOTING.md exists in the repository for exactly this class of problem.

Editorial conclusion

Adopt DroidDesk if you have an ARM64 phone, are comfortable in a terminal, and want a real X11 desktop rather than a remote session to someone else's machine. Skip it if you need an x86_64 workload, a supported product with an SLA, or display output from a phone whose USB-C port is data-only and you are not willing to run the Raspberry Pi Zero 2W bridge. Before committing, install Termux from F-Droid rather than the Play Store, confirm your phone is ARM64, and check APP_TROUBLESHOOTING.md for your OEM's background process policy, since the README warns that MIUI, One UI and stock Android 13+ may kill the session.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. orailnoor/DroidDesk on GitHub
4. README
5. Releases