GUADEC: porting GNOME to Android

Rightly or wrongly, GNOME is regarded by many casual users as "a Linux desktop environment." It also runs on various BSD and Solaris flavors, of course, and there has been considerable discussion recently of developing a "GNOME OS" deliverable suitable for tablets and other devices. But at GUADEC 2012, there was yet another spin on the redefinition of GNOME: porting several underlying GNOME frameworks to Android.

A team of developers from Collabora hosted the relevant session, which was titled D-Bus, PulseAudio, GStreamer and Telepathy In the Palm of your Hand. Reynaldo Verdejo Pinochet acted as ringmaster for the other speakers, and provided an introduction to the overall effort. As many others have observed, GNOME and other open source projects are facing a "form-factor challenge," he said. Desktop approaches to user interfaces do not work as well on small-screen devices, and mobile device users exhibit different usage patterns: rapidly interleaving multiple tasks rather than camping out in one application.

The open source developer community is currently failing to provide a bridge from the desktop to mobile devices, he said. Meanwhile, the system-on-chip vendors are turning their full attention to Android — a platform into whose development the community has no say. Collabora's solution, he said, is not to "fix" Android or to "fix" the users, but instead to enable the GNOME project's technology to run on Android. As a result, developers and users will have more choice, and the GNOME components will continue to be relevant to both.

The bulk of the session was then taken up by a series of short status updates from Collabora developers working on "smallifying" frameworks used by GNOME applications. Covered were Android ports of PulseAudio, Wayland, Telepathy, and GStreamer. Despite the title, D-Bus was not discussed separately in the talk; Verdejo said in an email that the D-Bus port was undertaken as part of the Telepathy effort. Verdejo closed out the session with general information for application developers looking to port GNOME applications to Android.

Porting stories

Arun Raghavan spoke first, explaining the PulseAudio port for Android. Android's native audio subsystem is called AudioFlinger (AF). It is a software mixer like PulseAudio, he explained, but it pales in comparison to PulseAudio for features. "It's not as nice as PulseAudio, and you can look at code if you don't believe me." In particular, PulseAudio provides flexible audio routing (including network routing), dynamically-adjustable latency (which prevents glitches, saves power, and simplifies the work required from applications), and support for passing compressed audio (in contrast to AF, which provides only PCM audio transport).

Although the project's original goal was to install PulseAudio in parallel with AF, Raghavan said, that quickly proved impossible due to how integrated AF is into Android. So instead, Raghavan focused on building and installing PulseAudio as a complete replacement for AF, using the Galaxy Nexus phone as the target platform. First, he successfully compiled PulseAudio and got it to run and play sound on the Galaxy Nexus. He then started work on using PulseAudio to emulate AF's playback API "AudioTrack," a task that he said is almost complete. Still in progress is emulation of AF's policy framework (which controls volume settings, when playback is allowed, and so forth). After that, the next item on the to-do list is "AudioRecord," the AF audio capture API.

Next, Daniel Stone presented the Wayland port. Once again, the goal was to offer Wayland as an alternative to a built-in Android service — in this case, SurfaceFlinger. SurfaceFlinger provides buffer transport functions analogous to Wayland, and composition functions like those of Wayland's reference compositor Weston. Collabora's port is mostly complete, and is currently able to run Wayland demos. Still in progress is integrating Wayland into the Android stack so that it can run side-by-side with SurfaceFlinger, a challenge that includes both running Wayland and SurfaceFlinger applications at once, and handling clipboard events, task switching, and other functions. Still to come is styling, which would make Wayland applications seamlessly match the SurfaceFlinger look.

The Wayland work ran into the usual porting problems, he said, but there were special difficulties as well. First, Wayland relies on several kernel features too new to be found in the Android kernel (such as timerfd and signalfd). Second, the Android graphics drivers are "terrible" at buffer management in comparison to the desktop. Whereas Mesa provides full EGLImage sharing through the Direct Rendering Manager (DRM) and seamless zero-copy transfers (which Wayland can take advantage of through the wl_drm extension), EGLImage is an "absolute crapshoot" on Android. The quality of the implementation varies drastically between hardware vendors, and the graphics drivers are almost always closed.

Alvaro Soliverez presented the port of the Telepathy communication framework. Telepathy is modular, supporting a long list of pluggable back-ends (from XMPP to SIP, to proprietary networks like MSN) and bindings for a number of programming languages and toolkits. Soliverez's port picked the subset most useful for Android: the Gabble XMPP module, link-local XMPP with Salut (using Avahi service discovery), and Java bindings.

The port is fully functional, he said, and the patches have been sent upstream to Telepathy. Android users can download and install the Telepathy service as a stand-alone application. In addition to the protocols mentioned above, the account management and status management functionality works, and the GLib bindings are in place for developers. Ports of the rest of the framework are underway, he said, although assistance would be welcome.

Verdejo discussed the GStreamer port. GStreamer is already successfully in use on other platforms, where it can serve as a bridge to the operating system's native multimedia framework (such as QuickTime on Mac OS X or DirectShow on Windows). The GStreamer Android port is intended to be a complete port of the framework, putting Android on par with the other platforms. This required the development of two new elements to interface to Android's media layer: GSTSurfaceFlingerSink and GSTAudioFlingerSink. These are sink elements, which allow applications' GStreamer pipelines to play their output on Android.

But the Android platform "is crippled on purpose," he said, offering no real native development story. Instead, all of the emphasis is placed on writing Dalvik applications. Consequently, Collabora decided to build GStreamer as a system-level service as well. It developed two other elements, GSTPlayer and GSTMetaDataRetriver, which can function as replacements for Android's built-in media playback functionality. Up next are new elements to handle direct multimedia output over OpenGL ES and OpenSL ES, and capture elements for camera and microphone input. The OpenGL ES and OpenSL ES elements will eventually replace the existing Android GStreamer sinks so that GStreamer pipelines will not need to depend on the Android API layer. All of the GStreamer work is being pushed upstream and will be included in the GStreamer SDK.

Developing applications

Verdejo Raghavan closed out the session with general advice for other developers interested in porting their software to Android. There are two general approaches to consider, he said: the native development kit (NDK) and the complete system-integration route. The NDK is Google's official offering, and it places some requirements on the developer — specifically, all of the application's functionality must be in libraries, which are then accessed by Java code using JNI. The libraries must also be bundled with applications.

The alternative route is to develop the software integrated into the Android source, which means it must subsequently be distributed as a custom Android build. The system integration route does allow one to make the software functionality available to the entire platform, he said, rather than just to specific applications (which is a limitation of bundling the library with an NDK application).

Whichever route one chooses, he said, there are "gotchas" to look out for. Android exhibits not-invented-here (NIH) syndrome, he said, right down to the basic C library: it uses Bionic, a "bastardized" version of libc with missing APIs and hobbled features. Android also uses unique Git repository and patch management tools written by Google, he added. But the main sticking point is Android's specialized build system, which relies on Android-specific makefiles. Maintaining those alongside the makefiles needed for another platform can be a considerable headache.

To simplify the process, Collabora created a tool called Androgenizer. Developers need to set up only a single top-level Android.mk file for the project and Android target rules in Makefile.am. The target rules call Androgenizer, which generates the makefiles Android expects (using Google's macros and Android-specific variables). Androgenizer can be used to generate makefiles appropriate for either NDK or system-integration Android builds, by checking for an environment variable called ANDROGENIZER_NDK.

The Androgenizer tool does not make building for Android trivial, he said, but once you figure it out, it only takes about 30 minutes for each new project. Although the process is not hard, Verdejo encouraged anyone working on an Android port to get in touch, saying the company is interested in helping.

All things considered, the ports of these and other frameworks from desktop GNOME (there are several other projects on display at the company's Git repository) offer an interesting take on the desktop-versus-mobile "problem." Typically the massive increase in mobile Internet devices is talked about as a sign that desktop projects are doomed; Collabora's GNOME-to-Android ports show that developers do not need to take that as a foregone conclusion, even for a tightly-controlled platform like Android.