Three short stories, all about Android

New toy

Thanks to some generosity on the part of Google's open source office, your editor is now in possession of a shiny new Nexus One handset. For some, this might not seem to be hugely exciting news; the Nexus One is another Android phone, and Android has been reviewed here before. That said, this device is noteworthy, to that point that its predecessor (an Android Dev Phone 1) has found itself headed toward early retirement.

As hardware goes, the Nexus is a beautiful device. It's less bulky than the ADP1, but it's far more capable. The screen is gorgeous and more responsive to touch than the ADP1 screen. The device has a real headphone jack, making it easy to connect to arbitrary audio systems. (On the other hand, the use of yet another mini-USB connector format for the charger is not appreciated). The camera works well and audio quality is good. Perhaps nicest, though, is the 1GHz processor, which makes this device the fastest and most responsive phone your editor has ever used.

The Android software has progressed somewhat beyond what is currently available for the ADP1. There is a 2.6.29 kernel (sort of - see below) and lots of eye candy. The device now has turn-by-turn navigation built into it - a great feature; it's just too bad that the voice that comes with it is so annoying. Your editor would suggest that anybody wanting a Nexus One, but lacking the resources to purchase one, could simply search alongside busy roads for handsets thrown out the window when their owners realized they simply could not listen to that voice any longer. "Goggles" will perform searches using the camera, which could prove useful for those "WTF is that?" questions. With the recently-pushed update, Google has finally incorporated multitouch into the device, even for those of us living in the USA.

The point of an open Android phone, though, is that one need not live with what the vendor has provided. The Cyanogen builds are the definitive alternative firmware for Android phones. As of this writing, builds for the Nexus are in a rather early state; in fact, only a beta image is available. There is also the obligatory enhanced recovery image out there. For the less adventurous, there is also an add-on image from Cyanogen which adds various command line utilities and an improved kernel to the existing firmware. Your editor hopes to be able to play with all of these in the near future, stay tuned.

Kernel participation

Greg Kroah-Hartman's recent discussion of the removal of the Android code from the staging tree contained little in the way of surprises, but it seemed to surprise enough people anyway to get a wide distribution. The problem here is simple: Google did its Android development work behind closed doors, then threw it out into the world as a fait accompli that was not subject to outside improvements. This code, unsurprisingly, was not seen as fit for immediate inclusion into the mainline kernel, even when non-Google people made the effort. It's a rare patch that doesn't need some sort of change; patches adding strange new features - some of which duplicate existing functionality - have an especially hard time.

Shipping new kernel features to users before being sure that those features will be accepted upstream can be a fundamental mistake, especially where new APIs are involved. Kernel developers tend to be cautious about API additions, since they must be supported forever; any API shortcomings need to be fixed before they can be merged. But if that API has been shipped to customers, the company responsible is faced with the choice of imposing an API change on those customers or maintaining the code as a fork.

Google seems to have taken the fork approach; indeed, recent comments from Google employees suggest that the company sees no problem with long-term forks. It is a little strange to hear that a few months after another Google employee gave a talk on how the company wants to work much more closely with with the kernel community. The kernel has been one of the unifying factors that has helped Linux to avoid the kind of fragmentation which plagued proprietary Unix and which we have seen in the BSD community as well. Google is doing a lot of things right; it has created a Linux-based phone platform which can compete with the best. It would be a shame, though, if Google were to do all this at the cost of bringing unwanted fragmentation to Linux.

Free applications

The Android "Market" gives access to a wide array of applications. Many of those cost money; others are free. There's even a button to select only free applications, for those who are not looking to pull out their credit cards at the moment. But "free," in the Android Market sense, is purely "free beer." Some of the "free" applications are indeed free software, but there is really no way for the user to know that or to look specifically for free/open source programs.

Twenty years ago, many of us were busily installing free applications on top of proprietary kernels and low-level libraries. The arrival of a viable free kernel made it possible to create 100% free systems, and large numbers of people have never looked back. Now, with Android, we have a free kernel which is heavily layered with proprietary applications on top. These applications cannot be changed or fixed, and they can lead to unfortunate situations like the cease-and-desist notice served against the Cyanogen build last year. They can also be loaded with antifeatures; your editor was recently put into the position of having to explain the "Unlimited girls on your G1!" ad helpfully displayed by WeatherBug to his spouse.

There are good free applications out there. The ConnectBot SSH client can be hard to do without. Astrid looks like a useful task manager; Tomdroid can be used in that mode as well. Android-wifi-tether is a hugely useful utility which turns a phone into a wireless access point connected through the cellular network. (Note that use of this tool may well put one at odds with one's cellular carrier; it also requires an enhanced kernel on some platforms). Your editor is not prepared to be quite so enthusiastic about the K9 mail client, but it is improving, slowly. Ringdroid is a good way to make your own special annoying ring tones. And so on.

Clearly, free applications exist for Android. But finding them takes work, which is silly; this is a perfect job for a computer. An ideal solution would be for Google to add a "freely-licensed" option to its (proprietary) market application. Failing that, it should be possible (for somebody with a bit more Android application-level programming experience than your editor) to put together an alternative market application which would focus on the growing body of free software for the Android system. It is an area worthy of encouragement; free software doesn't become less important just because it's running on a machine that fits into a shirt pocket.