Linux-based mobile phone platforms are really just specialized
distributions. Like other distributions, phone platforms will live or die
based on how well they meet the needs of their users. The Android platform
has a high profile at the moment as the result of the entry of more
handsets into the market, but also as a result of Google's actions toward
derived distributions. Android is clearly not meeting the needs of all its
users currently, but changes are afoot which may improve the situation.
The dust has mostly settled after Google's shutdown of the Cyanogen build for Android phones.
Nobody can really dispute Google's core claim that Cyanogen was
redistributing proprietary software in ways not allowed by the license.
But numerous people have disputed Google's good sense; those
applications are freely downloadable elsewhere and can only run on phones
which already shipped with a copy. So shutting down their redistribution does
Google little (if any) good, but it has had a harsh chilling effect over the
enthusiastic communities that were promoting Android and trying to make it
better. Now those communities are trying to regroup and continue their
work, but the rules of the game have changed.
The most community-friendly representative within Google has long been
Jean-Baptiste Queru; he clearly puts quite a bit of time into helping other
developers work with Android. He is now at the center of an effort to turn
Google's "Android Open Source
Project" (AOSP) into something deserving of that name.
Jean-Baptiste has (belatedly, one might say) figured out one of the major obstacles to
contributing to the platform: the difficulty of actually running one's
The primary target form factor for Android is a phone. That means
that, deep inside, a fundamental part of allowing writers to play
their part is to allow the Android Open-Source Project to be used
on phones. And, by that, I don't just mean that it needs to compile
and boot, i mean that it has to be usable as a day-to-day
phone. Right now, it's not. The range of applications is too
limited, the applications that are in there don't all work, and
there are quite a few system glitches along the way.
Another aspect is that it makes no sense to expect every
contributor to have to apply the same set of manual patches to get
to a basic working state. Android Open-Source Project should be
usable "out of the box" on commonly available hardware.
Anybody who has tried to build and install Android knows that this "out of
the box" experience is certainly not available today. Part of the problem
is the massive size and complexity of the Android platform as a whole;
there is not a whole lot to be done about that. But even owners of the
"Android Developer Phone," who might reasonably expect to be able to
develop for their
phones, have to locate a set of proprietary components and incorporate them
into the build. And then there's the problem of those proprietary
applications. A purely-free Android build lacks the maps, gmail, calendar,
and market applications - and the synchronization backends which keep
things current with the mothership. Such a build does not equip a
handset to be "usable as a day-to-day phone."
The first step, according to Jean-Baptiste, is to get to where an Android
build just works on the target hardware - the ADP1, naturally. Once the
hardware-level hassles have been overcome, it might make sense to talk
about filling in the missing applications. But until developers can easily
create a build that runs on a real handset, there's not much point in
looking at the bigger goals. With the upcoming
AOSP 1.0 release, it looks like this preliminary phase is nearing
Solving the rest of the problems should not be all that hard. If the gmail
application never becomes available, mail can be read through IMAP instead
- and that might just inspire some people to help improve the somewhat
painful email application currently shipped with Android. There is a lot
of interest in free mapping utilities, including tools like AndNav which have the potential to
surpass Google's maps program. AndNav works from OpenStreetMap data and
has the ability to do turn-by-turn navigation - something that the Google
tool is unlikely to ever be able to do. SlideME has been offered as a free replacement for the market
application. And so on.
The harder part might be the tools requiring synchronization with Google's
services; those protocols are not always open. It has been made clear that
the Android Open Source Project - hosted at Google - is not going to host
software developed for reverse-engineered protocols. So, if Google
continues to refuse to make the gmail, calendar, and market backends
available, those applications simply will not be supported in free builds.
There is, of course, nothing preventing the implementation of applications
which synchronize to services hosted elsewhere.
The other place where Google will make its presence felt in this project is
(L)GPLv3 is out of the question in all circumstances - it scares
the phone industry so much that we'd be hurting the entire Android
ecosystem if such code made it anywhere into the Android
GPLv2 might be allowed for new components, maybe, but given the extent to
which Android has gone out of its way to avoid GPLv2 software as well, it
could still be a hard sell.
Those looking for a more independent effort may be interested in the Open Android Alliance, which is
working to make a fully-free version of Android outside of Google. The
page (on Google Code, ironically) states that new work will be licensed
under GPLv3. It looks like the developers behind the Alliance are not
strongly tied to that license, but there are certainly developers out there
who would like to see some sort of copyleft license used. If Google is
going to hold back and make them reimplement applications, they reason,
Google should not be able to take the resulting code and distribute it as
another proprietary application.
The Open Android Alliance has a number of developers
who are said to be working on various aspects of the problem. It does not,
however, appear to have a mailing list or any code available for download.
This is a newborn project; its long-term viability is yet to be determined.
What is clear is that people take the "open handset" idea seriously. It is
not enough to dump a bunch of code into an online git server; many of us
actually want to mess with our devices. Google, perhaps, is starting to
understand that, even if it is still having a hard time balancing pressures
from the development community, wireless carriers, hardware manufacturers,
and its own lawyers. It is not yet clear whether that understanding
will translate into sufficient openness for the Android project, but it
appears that things might be headed in the right direction.
It seems that Linux World Domination in the handset market is within our
grasp. But which Linux distributions will participate in that success?
a number of Android handsets out there, but there are still more based on
other Linux distributions and the LiMo platform. Soon (not soon enough,
for many of us) there will be Maemo-based handsets to play with, and it
would not be entirely surprising to see Moblin-based handsets in the
not-too-distant future. Some of these platforms will do better than others
in the market. It may well be that the platform which is the most open,
and which draws the most developer interest, will win out.
to post comments)