By Jonathan Corbet
December 29, 2008
Your editor's long-suffering spouse will attest that gadgets are never in
short supply in the house. Many of them pass below her interest, but a new
one has come in which has attracted attention throughout the household: an
Android Dev
Phone, otherwise known as the fully unlocked version of the G1
phone offered by T-Mobile. This phone is certainly a fun toy, but it has
the potential to be a lot more than that.
The details of this device have been well publicized for a while now. It
includes a nice touchscreen display, QWERTY keyboard, GPS receiver,
accelerometer, 3.2 megapixel camera, and more. The whole thing is
powered by Google's Linux-based Android platform. The Dev Phone is
essentially the same device as that sold by T-Mobile, but with a crucially
important difference: it is unlocked in all senses. This means not just
that it can be used with any mobile carrier's SIM, but also that the base
operating software has not been locked down. This is a phone for which the
entire system can be rebuilt and replaced at will.
The Dev Phone thus joins the OpenMoko Neo Freerunner on the very short list
of truly open mobile handsets. This device, though, has the advantage of
being a bit more of a finished product with what appears to be a rather
stronger software development team behind it. It also, for what it's
worth, has some nice hardware capabilities that the Neo lacks: quad-band
GSM, 3G (though not on the bands used by your editor's carrier, alas),
keyboard, etc. Your editor believes that it will be a successful product.
Over the course of the next few months, your editor plans to dig into this
device and report on what he finds. How open is the device really? What does
it take to put a new kernel onto it? What might it take to put a different
operating system onto it altogether? And, in general, how does this whole
Android thing work? Assuming that he does not brick the device early on,
your editor hopes to get a real sense for what can be done with this
device, how close its software is to what we normally think of as Linux,
and where it might go into the future. It should be a fun project.
First, though, one has to get through the stage of simply playing with the
new toy. So the rest of this article will be a user-level review of
sorts.
The hardware: it feels generally solid. The device is larger and heavier
than handsets your editor has used in the past, but that is to be
expected. The keyboard works better than one might think given its size; even your
relatively fat-fingered editor is able to type with reasonable speed and
accuracy. The vibrator lacks strength. The camera seems to take nice
photos (for a phone camera), but it is exceedingly slow. As with most color-screen
devices, the display is entirely unreadable when the backlight is off. A
nice touch with this phone is an indicator LED which blinks when the phone
has something to tell you - an unread text message, for example - but the
use of the LED seems to be somewhat inconsistent.
Your editor has yet to get a sense for what the battery life would be in
the absence of children playing with the device all day long. Complaints
about battery life can be found on the net, but it appears that the phone
should be able to get through two or three days of moderate usage where the
GPS receiver is off most of the time. On the other hand, if you let your
kids use it to mess around on video sites, the battery runs down relatively
quickly.
On the software side, this phone gets off to a bit of a rough start. It
first requires the user to configure the phone to access data service from
the carrier, a process which must be done by hand if that carrier is not
T-Mobile. Your editor's last new phone recognized the carrier from the SIM
and handled this task automatically. More annoying, though, is that the
phone requires the creation of a Gmail account as part of its setup
process. The fact that one does not have - and does not want - such an
account is not relevant. So now your editor has an entry in the Gmail
account database which will never be used.
That, of course, ties in to why Google has gotten into this exercise in the
first place. There are many features of the Android platform which are
designed to tie the user in more closely to services provided by Google.
Some features, such as the calendar, are really just an extension of the
online offerings. The phone wants to sync the contacts list
to...somewhere...and turning the feature off leads to unpleasant behavior.
It is possible to use many of the features of the device without
connecting back to the Google mother ship, but it's not the natural mode of
operation.
Another example is email handling. There is a separate icon for Gmail which
just works; that application offers the features (such as threading)
provided by that service. One can run a different mail application to
connect to a POP or IMAP account somewhere, but it's a separate setup
process. Later, with luck, one discovers the improved K9 client, which must be
installed separately and which requires one to go through the setup process
again. Even with K9, the non-Gmail mail client is not what it should be.
There is no threading of messages, many basic commands (refiling messages,
for example) are missing, etc. Then there's little problems like refusing
to connect to a server if it doesn't think it can trust the SSL certificate
and failing to authenticate if the user's password contains special
characters. One assumes that this client will improve,
or that other clients will be ported to the platform, but, for now, it
doesn't seem to be a priority for the Android developers.
More generally, though, the Android software is pretty slick. A fair amount of
thought has been given to how interaction should work on this kind of
device. Once one gets used to a few specific differences (holding a finger
on an item on the screen for a few seconds often brings up otherwise hidden
options, for example), navigating through applications comes fairly
naturally. Only in some cases do inconsistencies pop up - some
applications have different notions for how to zoom in and out than others
is one that your editor has noticed. As a whole, the interface comes
across as polished and attractive.
That said, use of the display could be improved. On a small display, there will
always be a certain tension between getting enough information on-screen
and avoiding the creation of headaches through severe eye strain.
Different users will do better with small fonts than others. But if
Android offers an option to configure default font sizes, your editor
cannot find it. So it becomes necessary to manually zoom almost every web
page, almost every email, etc. to get a sufficient amount of information
onto the screen. That gets a little tiresome after a while.
The "Android Market" offers a wealth of applications, most of which are
available as free software or, at least, in a free-beer mode. When
browsing applications, one runs into the Android security model, which is
oriented around a
long set of capabilities which can be granted to applications. A
program which needs do things like access the net, obtain location data,
change hardware settings, etc. must declare the capabilities it needs;
these are then presented to the user at installation time. Most users will
probably just say "yes," but it is worth taking a closer look. Your editor
decided to decline the installation of a Mahjongg game after being unable
to figure out why it was asking for full network access.
Beyond the inevitable games (including one of the worst Tetris
implementations seen in a while), there is a wide variety of available
applications. The "Locale"
tool makes up for the (surprising) lack of the sort of "profile" feature
found on almost every handset your editor has ever seen; it performs tricks
like using the GPS
receiver to automatically change profiles when the phone enters the office
or a theater. The "bubble" application (shown on the left) turns the
handset into a portable
level. There's no shortage of "smart shopper" applications, most of which
can read a barcode using the camera and look up prices for items. There is
a "power manager" which attempts to configure the device for optimal power
use in a number of situations; it provides a basic profile functionality as
well, though the user should be prepared to spend some time configuring the
options into a workable form.
There's plenty of travel-oriented applications which will fetch weather
reports, currency rates, or call a taxi.
One notable omission, with both the base phone and the available
applications, is voice over IP functionality. This handset should be able
to do VOIP beautifully, but almost no such functionality is available.
There appears to be a tool for Skype users, but that's about it.
There are a couple of applications that are of particular interest to your
editor. ConnectBot is
an SSH client which works surprisingly well; the developers are clearly
working toward the creation of a tool useful for people logging into
Linux-like systems. And the terminal emulator provides that all-important
feature: a shell prompt on the device. Even more fun, on the Dev Phone, a
simple "su" with no password will yield a root shell.
Playing around on the device, your editor sees that the ARM processor
provides a mighty 383 bogomips. It appears to have a little over 100MB of
usable memory. It's running a 2.6.25 kernel (known to be heavily modified)
with a single loadable module called "wlan." And so on. As useful as the
keyboard is, trying to use it to type commands at a shell which lacks a
history mechanism gets painful after a while. Time to go looking for an
SSH server.
There are other useful applications, of course, such as the one which actually
makes phone calls. Like the others, it lacks perfection, but one can only
assume that, on a platform driven by free software, that imperfect
applications will be improved or replaced. How easy it is to do such
things is part of what your editor intends to find out in the coming
months. Stay tuned.
(
Log in to post comments)