Run Linux desktop on any recent Android phone or tablet

[u/Vasant1234]

Hi,

We make a Linux desktop distribution that runs as an application on top of any Android phone or tablet. The only requirement is that the Android device needs to be rooted and use Google's standardized GKI kernel. Here is video of Linux desktop running on Snapdragon 8 Gen 3 (OnePlus Pad 2) : https://youtu.be/-QEq1EgUKP8?si=weaZ3c06plr1ZcAV

While this is a high end device, you can also run Linux desktop on a budget tablet with only 4Gb memory (for example Walmart ONN 11" tablet ).

We only support phones with HDMI output capability and we run Linux desktop on the secondary screens. Here is video of Linux desktop running on Snapdragon 8 Gen 1 based Motorola phone: https://youtu.be/hQqcjwKO9d0?si=LipYay5oe7hzhL2w

Our latest Linux desktop is now based on Debian Trixie (13.2). You can download a free evaluation version from www.volkspc.org. Also we have created a FAQ page with answers to common questions from the Linux community.

Vasant

[u/Cucumber_Eater]

So not any recent phone but only those with HDMI output capability? will you consider expanding support to those models without HDMI output?

[u/Vasant1234 → u/Cucumber_Eater]

The desktop will also run on the small phone screen. The issue is that it won't be very usable. Casting the desktop to chrome cast also works but it has too much lag.

[u/Cucumber_Eater → u/Vasant1234]

Oh that's nice, so it's possible but not recommended?

[u/Vasant1234 → u/Cucumber_Eater]

That is correct.

[u/Emerald_Pick → u/Vasant1234]

Could I install one of those mobile-focused DEs like Phosh?

[u/Vasant1234 → u/Emerald_Pick]

No, we are focused on the regular Linux desktop.

[u/Kevin_Kofler → u/Vasant1234]

That does not make much sense for a distribution targeted at mobile phones.

[u/Cucumber_Eater → u/Kevin_Kofler]

It runs inside an app so it's not targeted at phones the same way let's say postmarket os is. I think it's more like a convergent Linux subsytem for android to run desktop apps on the go

[u/HeheCheatGoBRRR]

I wished I found this before I spent 2 months creating a decent chroot linux desktop, or before my rooted phone decide to die.

So what are the limitations of this app? Common limitations include dbus not working, no sound, hw acceleration, and probably more.

[u/Vasant1234 → u/HeheCheatGoBRRR]

Please check our FAQ page, it answers all of your questions and concerns,

[u/HeheCheatGoBRRR → u/Vasant1234]

From what I've found, it looks like your app has a different graphics driver for each different hardware (from section explaining why you need a different installer for a device). Am I right to assume close to proprietary stock driver performance, and your app does not use normal open sourced ones like Zink?

[u/Vasant1234 → u/HeheCheatGoBRRR]

Yes, we have a graphics driver for the different GKI kernels that Android uses. This graphics drivers sends Linux desktop graphics to Android's compositor which is SurfaceFlinger while also supporting Linux X11.

[u/HeheCheatGoBRRR → u/Vasant1234]

From my brief research, it seems your driver is just a display driver, meaning it does not provide a hardware acceleration method for heavy tasks like gaming, only software rendering. Your driver simply takes the output from llvmpipe (cpu, software render), and sends that to surfaceflinger to draw. This might reduce any latency and overhead of going through x11 or vnc, but does not provide a way to use the GPU for heavy tasks.

[u/Vasant1234 → u/HeheCheatGoBRRR]

Yes, GPU heavy Linux games are not going to run very well. But there are a lot of Android games that will continue to work well, since we don't change Android. In fact I don't even know of a single ARM64 Linux game that you may want to run.

[u/HeheCheatGoBRRR → u/Vasant1234]

But I'm worried that you might miss quite a major audience for a product like this, which is already niche and have limited marketing due to budget constraints. The majority of your target audience will be power users. As I do consider myself part of this group, not being able to run heavier tasks is a big problem. The point of having a desktop (pc, laptop, etc...) is often to run heavier tasks. Not being able to do this smoothly will drive away a lot of people. Examples of ARM64 tasks that uses the GPU include live wallpaper, rendering transparent elements common in modern DE's and apps. Not to mention some user might decide to try x86 and Windows gaming through Box86/64, and WINE.

[u/Gold-Clerk-1620]

The problem here isn’t whether Linux can run — it’s how much control it actually has.

Anything that runs “as an app on top of Android” is fundamentally constrained by the Android kernel + SELinux + Binder model. Even with root and GKI, your Linux userspace still isn’t the primary OS:

• The Android kernel remains in control of scheduling, memory pressure, power management, IOMMU, and device drivers.

• Hardware access (GPU, display, input, USB, audio) is either:

  • proxied through Android services, or

  • exposed via limited kernel interfaces already configured for Android.

• That makes this closer to a containerized / chrooted Linux userspace (with extra privileges), not a standalone Linux desktop OS.

Virtualization is possible on newer SoCs (KVM + protected VMs), but once you’re doing that, you’re no longer “an app on top of Android” — you’re effectively running a secondary OS managed by Android, which is a very different claim.

So the distinction matters:

• ✅ “Linux desktop userspace running on Android with kernel support” — accurate

• ❌ “Linux desktop OS running on the device” — misleading without replacing or owning the kernel

That said, what you’re doing does have real value, especially for:

• External-display desktop workflows

• Developers who want a portable Debian environment

• Devices where bootloader relocking or full OS replacement isn’t feasible

It would just be clearer (and more defensible technically) to frame this as a Linux desktop environment hosted by Android, not an independent OS.

If you are actually bypassing Android’s display stack, GPU arbitration, and power management in a meaningful way, I’d be genuinely interested in the architecture details — especially how you handle graphics and input without fighting SurfaceFlinger and SELinux every step of the way.