Android X server

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.

and . 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.