This article is currently an experimental machine translation and may contain errors. If anything is unclear, please refer to the original Chinese version. I am continuously working to improve the translation.
This article documents my recent exploration into turning Android phones/tablets into productivity devices, covering a wide range of software and hardware topics.
Reality Check
First, let me be clear: the main purpose of researching these methods isn’t to seriously replace a PC or use Android as a primary development tool. The ultimate conclusion of this post is that, even under the best circumstances, using Android as a programmer’s main development environment will significantly reduce productivity.
If you genuinely have portability needs, I’d recommend getting a mini PC around 0.5L in size, or laptops like the LG Gram.
Mini PCs in the $100–200 range generally match the performance of common ultrabooks and are easy to carry between locations (just pair them with a monitor and peripherals at each spot).
If you need mobile work capability and battery life, consider ultrabooks like the LG Gram / Dell XPS / ThinkPad X1. While their performance throttles under load, models like the LG Gram offer excellent battery life while delivering full Windows functionality. Brand-new top-tier models can be expensive (>$1000), and if you’re on a budget, consider buying one- or two-year-old new units ($700–1200), or even used ones from secondhand markets like Xianyu — replacing the battery afterward makes them perfectly usable ($150–300).
Of course, we can also look forward to the upcoming Snapdragon X Elite.
The real goal of this blog post is to explore the boundaries of what modern Android devices are capable of (aka: pointless tinkering), such as:
- Can we repurpose old Android phones as Linux servers?
- Can we run Docker / LXC containers on Android?
- Can we run Windows applications or experience Windows on Arm?
- In extreme cases
(e.g., high school)where carrying a laptop is not allowed, how far can Android go in fulfilling real productivity tasks? - If you don’t trust your main computer, can your Android phone serve as a portable, self-controlled “trusted” computing device?
Android Video Output
To function as a productivity device, Android needs a decent-sized screen to read text clearly. Android tablets naturally meet this requirement, but getting video output from phones to external displays is trickier. If you have access to a computer, scrcpy is a solid option — but here we want Android to directly output video signals to a monitor without any intermediary.
Currently, only a small number of phones natively support video output over Type-C. Owners of these devices can simply buy a common Type-C to HDMI dock and be good to go. Huawei and OPPO, however, don’t allow rooting — and no root access? No thanks.
For most Android phones without native video output, things get complicated. After some digging, I found an older technology called DisplayLink.
To use DisplayLink, you need to install DisplayLink Presenter on your Android device and purchase a DisplayLink-compatible dock. The idea is simple: the app captures your screen, encodes and compresses it, then sends it over USB to the dock, which decodes it and outputs an HDMI signal.
DisplayLink-compatible docks aren’t common, especially newer models (most have switched to pure Type-C video), but I found a few old ones on secondhand platforms for around $15 (search for “DisplayLink”). I bought an HP TPA-i502, along with a compact PD-charging-capable hub so I could charge and connect the display simultaneously.
Stacking buffs: PD hub + DisplayLink hub, connected to mouse, keyboard, power, and monitor
In practice, the latency is surprisingly low — around 10–20ms — and the quality is decent 1080p60Hz.
Remote Desktop / Streaming
We’ve covered how to get Android to output video. If you own a desktop or server, remotely connecting back to it via remote desktop seems like a viable alternative. In fact, using an Android tablet with a keyboard and mouse for remote Windows work is already a fairly common setup.
There are several remote desktop protocols available. Ignoring some sketchy Chinese commercial solutions, the main options are RDP and streaming-based protocols. The former works well for general desktop control; the latter was originally designed for gaming but can also be used for desktop streaming. I tested RDP, Moonlight, and Parsec. Overall, I found RDP the most reliable. (My server is accessed over the internet — streaming protocols demand more bandwidth and tend to lag. If you’re on the same LAN or close network, streaming might be better — try them out yourself.)
The biggest issue I encountered was that certain system-level shortcuts on Android can’t be overridden by apps. During remote sessions, keys like Windows or Alt+Tab trigger Google Assistant or app switching instead of being passed through.
After some research, I discovered that Android’s Accessibility API can be used to capture all system key events, enabling near-perfect remote desktop behavior. I implemented this for both aRDP and Moonlight Android (and filed upstream issues [1][2]). However, due to strict Google Play policies around Accessibility services, upstream may not accept these changes:
aRDP: https://github.com/lyc8503/remote-desktop-clients
Moonlight: https://github.com/lyc8503/moonlight-android-no-keyboard-shortcut
Windows on Arm
Microsoft has released Windows on Arm, and Qualcomm has launched several desktop-class SoCs, gradually building an ecosystem. This has also made running Windows on Android devices technically feasible.
Enthusiasts have started porting necessary drivers to Android platforms, including the international WOA Project and China’s Mindows Toolkit.
A prime example is the Xiaomi Pad 5, where drivers are mostly complete and the system is roughly usable. Given its tablet form factor, it’s currently one of the best devices for experiencing Windows on Arm.
Many Snapdragon 835, 845, and 855 phones are also on the supported list (though support is often incomplete). Check the official Mindows site for compatibility. Once Windows is installed, pair it with a DisplayLink dock for video output, and you’ve got a working Windows-on-Android setup.
KVM Virtualization
While researching, I belatedly discovered that starting with the Pixel 6 series, Google has enabled KVM support on ARM for Pixel devices. Yes, you can now run full virtual machines on Android using hardware-assisted virtualization — meaning you can easily run full-fledged Windows or Linux. (And yes, this works even without root.)
After years of frustration with Xiaomi (see below), I’m making a vow: my next phone will be a Pixel.
Side note: Armv8 architecture itself supports virtualization, but almost all phone manufacturers configure the firmware to run Android at EL1, without exposing the virtualization interfaces. The firmware is often permanently locked (fuses blown), so users can’t modify it — unlike PC BIOS, which users can reflash.
Linux Deploy
The Windows/KVM solutions above require specific hardware support. For the vast majority of other devices, there are still ways to run Linux.
Linux Deploy is one of the earliest methods I used to run Linux on Android. It requires root access and works by using chroot to switch into a Linux rootfs, then launching sshd so you can SSH in. Back when devices were still 32-bit ARM, I used this setup on old phones and hit countless roadblocks.
More recently, there are rootless alternatives like Proot, which implements chroot-like functionality in user space — meaning any Android phone can run any Linux distribution without root.
Fun fact: this very blog post was written inside a LinuxDeploy environment — running Arch Linux ARM, with i3, Chromium, and an input method — all accessed through GitHub Codespaces.
The actual scene of writing this blog — who needs a laptop anyway? (x)
Docker / LXC
LinuxDeploy only isolates the filesystem via chroot. All other resources (like processes, networking) remain shared. This causes systemd to refuse starting (since pid != 1), rendering systemctl and all service management unusable. You have to manually start daemons. Even dbus, essential for desktop environments, must be launched manually.
Android, being a form of Linux, usually ships with kernels that lack support for LXC features. However, if the manufacturer has released kernel source (as required by GPL), you can recompile it with the necessary options enabled. (Unfortunately, my Xiaomi phone only released the initial kernel version and never updated it — so the open-source kernel only supports Android 11.)
If you want to try compiling a kernel with LXC support, check out this gist.
BTW, Google’s new GKI initiative has helped end the era of fragmented Android kernels. It standardizes the kernel layer and even enables easy kernel modifications (e.g., via KernelSU). If your device uses a relatively recent kernel (5.5+), you may be able to use a generic kernel image without relying on the manufacturer to publish updated sources.
Final Thoughts
As mentioned at the beginning, this isn’t really about using Android as a serious productivity tool. Let’s treat this conclusion as some off-topic musings.
Unlike the unified, open standards of the x86 world, the ARM and Android ecosystem remains a fragmented, chaotic landscape.
On one hand, Google’s GSI and GKI efforts are helping reduce fragmentation. With strong influence (and enforcement power) in the Android space, their Pixel devices often debut cutting-edge features.
On the other hand, the high level of integration and customization in Android devices makes it easier for Google (and OEMs) to exert control. Play Integrity now uses the SoC’s TrustZone for device integrity checks — effectively locking users into manufacturer-approved configurations. When “trusted computing” is misused, we drift further from the open, free internet we once had.
I believe that since consumers pay for their devices, they should have the freedom to modify them. DRM shouldn’t be an excuse for manufacturers to control devices that belong to users.
Xiaomi recently tightened its Bootloader unlocking policy. If I can’t easily unlock my bootloader, I won’t buy Xiaomi again. The future of Android lies in the hands of OEMs — but it seems like the needs of a minority are ignored as if it’s completely normal.
This article is licensed under the CC BY-NC-SA 4.0 license.
Author: lyc8503, Article link: https://blog.lyc8503.net/en/post/android-productivity-and-more/
If this article was helpful or interesting to you, consider buy me a coffee¬_¬
Feel free to comment in English below o/