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
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
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
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.
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
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
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
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
[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC.]
to post comments)