Android X serverPosted: February 27, 2012
For the past few months I’ve been implementing an X11 server to run natively under Android. In the near future I may have need for a serializable user interface, so to get a better understanding of how they work I decided to implement the de facto standard, X11.
Well, it turns out the X protocol is bigger than I thought, but through sheer bloody-mindedness I got it finished. And it might actually be useful.
I had assumed that all internet-enabled smartphones would be sitting behind NAT-ing routers, both for security reasons and to conserve IPv4 addresses. But no, on the “3” network in Australia at least, phones all have externally-accessible IP addresses, meaning they can run servers. So you could potentially launch a Linux X application out in the cloud and have it display on your phone.
The user interface is fairly simple: touch the screen to move the pointer, and use the directional pad to activate the left/middle/right buttons. Update: the volume up/down buttons now work as mouse left/right buttons. Both virtual and physical keyboards are supported.
The source code is available at
http://code.google.com/p/android-xserver/ https://github.com/mattkwan/android-xserver/ under an MIT licence, and the application (called X Server) is available for free through the Android Market Play Store.
There are a few parts of the X protocol it doesn’t implement …
- Dynamic colourmaps. Android only supports a 24-bit static colourmap.
- Dashed lines, tiles, and stipples. There’s no native support for these in Android, and seriously, does anyone use them?
- Drawing operations other than Copy and Xor. That’s all Android supports.
- Queueing keyboard and pointer events during grabs.
- Most extensions. XGE, XTEST, BigRequests, and Shape are implemented, bit that’s it. There are hooks provided in the code, so if you’re feeling ambitious, try implementing some others. Quite a few applications use them.
- Key click, auto-repeat, and keyboard LEDs.
The server also ships without a window manager, which is a problem because a number of applications expect one to be running. The code includes a parameter specifying an Android service to be launched once the X server is running, and this is intended to start a window manager. But first someone will have to implement a window manager in Android, and doing that properly requires a re-implementation Xlib. Not me, I’m afraid.
However, there is a workaround. Because access control is disabled by default, you can run a window manager remotely, e.g. fvwm -d xxx.xxx.xxx.xxx:0. Not very efficient in terms of network traffic, but it works.