I'm a bit late with my obligatory Android post. Partly that's
because I wrote this in a lab at university a while back and forgot
to post it.
The announcement of Android and the release of the "early look"
SDK have created quite a bit of hype. There have been numerous
similar announcements by other initiatives to get Linux on mobile
devices, so what's with the excitement about Android?
Of course, it's backed by Google. Whether you like it or not
there isn't going to be a way around it. But that's not all there
is to it. The engineers behind Android have simply done an
excellent job judging from the SDK. And there's a lesson or two to
be learned by the open source world:
-
The Linux kernel is good at what it does. Userspace is
generally not worth bothering with.
I found this very striking. If you have a look at what's
running in the emulator (which is based on Qemu), you'll notice
that there are just a few processes and the only standard component
among them is dbus.
Android uses a custom (launchd/upstart-like) init replacement.
Traditional, SysV style, init systems waste a lot of time just
forking shell processes. And doing stuff in shell also opens the
door for monstrous shell scripts that spend ages performing simple
tasks such as
creating a few files and directories (that script takes 5-10
seconds to run). It still takes a while for Android to boot though,
which I hope is just because my laptop is slow.
Android also doesn't bother with providing a complete Unix
commandline environment, since, hey, the user isn't going to see
that anyway. It's funny how it's never occured to me to stop
shipping the lower layers (non-essential bits of busybox, login).
But then again, I'd probably have been yelled at for that by some
users...
I have yet to check whether udev or a udev replacement is
involved as that tends to be a bit of a bottle neck on resource
constrained devices. It would certainly be nice to either get
things to work without udev or with a more efficient replacement.
The other thing I have yet to figure out is whether any type of X
is involved in windowing. At a glance, it doesn't look like it
though.
-
You can build efficient security models that are still
simple enough for people to actually use them.
Most PDA/phone stacks make the assumption that only one user
uses the system. Personally, I prefer multi-user environments so I
can lend devices to friends/family, but for the average user that
assumption is reasonable.
In a multi-user environment you need technologies like SELinux
to separate individual applications run on behalf of a single user.
Mobile stacks have to my knowledge (apart from an extremely locked
down set of Motorola phones) up to now never bothered with that.
Applications either all run as (yuck!) root (Qt/Embedded, Qtopia)
or as a single user (GPE, Maemo, Poky, OpenMoko) without any
significant restrictions as to what individual applications are
allowed to do.
Enter Android... Why not re-use the space freed by the
single-user assumption and run each application as a separate user?
Sufficient for most use cases and still very simple to understand.
Security models only matter if they are simple because they won't
be used otherwise. It remains to be seen how well the Android
security model works out in practice but I like the concept.
-
It's not a platform unless it comes with a comprehensive API
and an easy to use, well-integrated SDK.
I found it rather amusing how people referred to OpenMoko as the
first open platform in reaction to the Android SDK release. At
present OpenMoko is a prototype device plus a number of mockups and
a few prototype applications. There's a long way to go to turn that
into a platform.
First of all, developers will want a comprehensive API. From
experience talking fellow developers through GLib/GObject/Gtk+/etc.
development basics, it's fairly obvious to me that just throwing a
bunch of libraries at people doesn't do the trick. People get lost
too easily around the borders between the territory covered by the
different libraries involved. Arguably, this is mainly a
documentation problem, but there's more to it. Following the
development of the Gnome desktop throughout the years shows that
people spend a lot of time discussing at which level to implement
functionality, shuffling bits around, etc.
Android takes a different approach. Using the Java programming
language allows integration with Eclipse (or similar commercial
IDEs) which provides developers with API documentation right in the
editor. Combine that with refactoring/reenginering features of
modern Java IDEs and you'll never look back to anything else.
And the level of integration goes beyond that. You don't even
have to leave Eclipse to upload your application to the devices.
It's all just a matter of clicking a few buttons. For an "early
look" SDK that's rather polished and provides a new level of
efficiency compared to what I'm used to on other Linux based
systems.
-
The primary goal must be to attract developers. The larger
the set of potential developers the better.
If you want people to use your stuff you'll have to make it easy
for them to hop on the train. As simple as that may sound, most of
the time it just doesn't work like that.
I believe the choice of Java as the programming language was the
right one. Personal taste aside, there is hardly any way around
Java. It's the de-facto standard first language in teaching around
the world.
It remains to be seen whether there will be other language
bindings in the future. It doesn't seem very likely to me though,
since Google probably wants to avoid a mix of languages which
easily leads to a giant mess.
-
Avoid cross compilation and complex build systems.
People tend to spend a lot of time setting up a cross toolchain,
fighting applications that won't cross compile cleanly, etc. That's
a major waste of time.
Of course there are various meta-level build systems, which try
to hide that sort of thing from you. But that comes at the price of
another level of indirection and complexity. There are very few
people who actually understand how, say, OpenEmbedded works under
the hood in every detail - the problem being that in certain cases
you need that level of understanding to get your work done.
Android's take on this is to avoid cross compilation and build
systems altogether (for application development anyway). I like the
approach. It's very refreshing to find a development environment
that you can instantly work with after downloading. My first simple
application ran in the emulator within minutes.
People have raised the question whether Android renders various
other projects obsolete. And, realistically, I think it will once
fully open source under a permissive license. The impact will be
dramatic. As outlined above, traditional handheld distribution
paradigms along the lines of a "base system" are shown to be
irrelevant and there's been a clear focus on creating a fun
developer and user experience.
Do I sound overly optimistic for the success of Android?
Perhaps. I haven't held a device running Android in my hands yet
after all and there are licensing questions to be
sorted out, too. Given the list of consortium members behind the
Open Handset Alliance, however, I'm confident there's some
exciting, well engineered stuff ahead.
