The Android developer phone (ADP1) is a nice piece of hardware which allows
freedoms that the T-Mobile standard-issue G1 does not allow. As the name
might imply, it is targeted at developers so that they can more easily
develop applications for the Android Market, but also so that they can
hack on the Android platform itself. So far, though, the Android
development community has been less-than-satisfied with the development
support provided by Google. In fact, the recent decision to disallow access to
copy-protected applications in the Android Market has a lot of
ADP1 purchasers up in arms. But that isn't the only thing that has
annoyed—or worse—Android hackers.
The idea behind a developer program is, or should be, that developers get early
access to the code that customers will soon be running, so that they can
test their applications—finding and fixing bugs before the general
public ever sees them. For whatever reason—manpower is the
oft-stated problem—Google has turned this on its head. Customers who
purchase the consumer version (i.e. G1), will get the RC33 version (in the
US, European version numbering is different) of the
firmware. The G1 phones ship with an earlier version, but an over-the-air
upgrade will eventually bring them up to that version. For developers who
purchased an ADP1, however, there is no equivalent upgrade, at least
There has been a fair amount of complaining about the lack of an ADP1
upgrade on the android-developers
mailing list. Jean-Baptiste Queru, who seems to be the Android engineer
who was selected or volunteered to answer questions on the list, is
unhappy about the delay—and lack of
There's no news on that subject as there isn't anything to announce
yet. We're still pushing hard to get 1.1 available for ADP1 owners,
but some things take time and no matter how quickly we want them done
we can't skip the necessary steps.
[...] You're not the only one frustrated about this. I am too.
The 1.1 firmware release for the ADP1 is supposed to have more-or-less
equivalent functionality to the RC33 release for the G1. But what,
exactly, that release will contain is still a closely-held secret.
That seems to be one of the biggest complaints about how Google is treating
Android developers: lack of information. The problem with copy-protected
applications for the ADP1 is just another example.
Android offers application developers two restrictions that they can apply
to their programs in the Android Market: for-sale and copy-protection. It
is believed that most for-sale applications will also carry the
copy-protection restriction, but that is not required. Gratis applications
can also be copy-protected if the developer wishes to do so.
The ADP 1.0
code does not allow access to either kind of application in the Market.
ADP 1.1 is believed to relax that restriction to only those that specify
copy-protection, though that may not be much different in practice. The
reasoning, according to Queru, is that
"copy-protected apps aren't offered on devices where the
copy-protection is known to be ineffective." Because the ADP1
phones are unlocked, there are various ways that the copy protection
could be overridden.
The fear seems to be that developers might pay for an application, then
squirrel it away and apply for a refund. Developers could restore the
deleted application after receiving the refund or copy it to other
phones. While that is a possibility, it
leaves some feeling like developers are being
singled out as pirates. One of the problems is that folks who have
gotten root access on their G1 phones can access copy-protected
applications. In the end, folks who want to pirate applications—be
they developers or consumers—will find a way to do it.
It is a time-honored tradition amongst software developers to check out the
competition. Many of the hobbyist developers hoping to strike it rich with
Android Market applications purchased the ADP1 in the belief that it would
have the same functionality that the consumer version does. Now they have
found out that they can't purchase competitor's applications (at least in
the likely case that they are copy-protected), on top of the realization
that they can't get a blessed version of the latest code. Other ADP1
purchasers were looking to get around the geographic and/or cellular
carrier restrictions of the G1, but now have a phone with fewer capabilities.
There are alternative firmware loads for
the ADP1, but it doesn't sit well that Google has yet to provide one. A
somewhat popular alternative is to use the so-called "holiday"
version—the version that shipped on the ADP1s that Google
gave its employees as a holiday bonus. Interestingly, that code does not
allow accessing copy-protected Market applications either, which makes it
likely that the restriction is simply an attempt to be consistent about
copy protection, as Queru stated, rather than a real belief that developers
are more likely to be pirates.
Google could have avoided much of the outcry by being more
transparent—something the company seems to have a general problem
with—and by paying more attention to its developer program. The
blog does not seem to cover many of the areas that are of concern
to the community. One must wander through the mailing list or third-party
sites to find information about the restriction on copy-protected
applications, for example.
There are alternative mechanisms for handling copy protection, of course.
Several were bandied about on the mailing list as the "forward
locking" scheme—essentially signing the application in such a way that it
won't run on other phones—is seen as suboptimal. The
alternatives are other forms of DRM, however, as Queru points out:
No doubt that using a DRM solution that is not based on
forward-locking is the right long-term approach. We know what it would
take to implement it. There just wasn't enough time to do it.
Developers just want a phone that can do what they need it to, so some are
starting to feel like they made a bad decision by purchasing the ADP1.
That has led to suggestions that
folks should just sell their ADP1 and use the emulator or a G1 phone to
do their development. That may be a bit of an extreme reaction, but there
are probably some who have done that or are considering it. A bigger worry
for Google might be that they decide to ditch the Android platform entirely
for something more developer-friendly.
Some have portrayed Android as the future of the Linux desktop—on
phones and netbooks at least—but the problems that are currently being
experienced on phones could well spill over. DRM and
locking devices to particular vendors are not "features" that people normally
associate with Linux and free software, but they are being demanded by some
vendors. Those kinds of restrictions are really meant to keep consumers
from reaping the benefits of freedom. While folks may be used to that
treatment from mobile phones, one hopes they don't have to get used to it
from their computers as well.
Comments (22 posted)
Almost two years ago, your editor sat on an Open Source Business Conference
panel with Microsoft's Sam Ramji, who made the point that Microsoft had
only launched patent infringement lawsuits twice in its existence. Given
that, worries about the Microsoft/Novell patent deal were, in his opinion,
week, it was revealed
the count has gone up to three: Microsoft has filed a lawsuit against
TomTom, a maker of Linux-based navigation devices. There is much
speculation and uncertainty on the net as to just what this action means.
Your editor means to add to it by saying that Microsoft's intentions would
appear to be relatively clear.
The patents which TomTom is alleged to be infringing are:
(Vehicle computer system with open platform). This patent, filed in
1999, covers the innovative concept of mounting a computer in a
vehicle dashboard. Literally, that is all there is to it.
(Vehicle computer system with wireless internet, 1999). This one
extends the previous patent by adding an Internet connection to the
(Method and system for generating driving directions, 2003), appears
to cover the basic turn-by-turn instructions provided by just about
any navigation unit on the market.
(Methods and Arrangements for Interacting with Controllable Objects
within a Graphical User Interface Environment Using Various Input
Mechanisms, 2000). This patent is relatively impenetrable, but
appears to cover a framework for binding responses to user interface
(Portable computing device-integrated appliance, 2005). The deep
concept here appears to be recognizing a docking station and causing
the user interface to configure itself accordingly.
(Common name space for long and short filenames, 1995) and 5,758,352
(Common name space for long and short filenames, 1996). These are the
infamous patents on the long filename hacks embedded in the VFAT filesystem.
(Method and System for File System Management Using a Flash-Erasable,
Programmable, Read-only Memory, 1992). This one covers a fairly
straightforward mechanism for managing flash memory by dividing large
erase blocks into filesystem-sized blocks and allocating them
The first two patents in this list appear to be laughable indeed; it is
hard to see how they can pass the obviousness test. This is especially
true in light of the KSR v. Teleflex
ruling, wherein it was decided (also in the automotive setting) that
the idea of
connecting a floor pedal to an electronic throttle control was too obvious
to patent. The navigation patent would appear to be infringed by anybody
who sits in the passenger seat and helps the driver find a destination.
The docking station and GUI patents seem less clear, but it doesn't seem
like it should be all that hard to find suitable prior art.
That leaves the final three patents, all of which are relevant to the Linux
platform. Like almost every other system on the planet, Linux supports the
VFAT filesystem, and, thus, could be argued to infringe upon the relevant
patents. The flash patent looks much like the technique used by any system
which manages flash memory in anything but the stupidest of ways. It would
appear that Microsoft has finally decided to follow through on its
longstanding patent threats against Linux.
Of course, not all agree. The 451 Group posted this
fairly impressive apology for Microsoft, claiming:
The key phrase, which is repeated, is the suit involves 'the Linux
kernel as implemented by TomTom,' which is very different from 'the
Linux kernel' when we're talking software code and patent
For those looking for signs that Microsoft has changed, I would
hope this might serve as the proverbial coffee to wake up and
smell. Microsoft is acknowledging the contributions and IP value of
open source software and is going out of its way to make sure
people don't think it is making patent infringement claims over the
actual Linux kernel.
Your editor wishes to politely dismiss this talk as dangerous nonsense.
There is nothing special about TomTom's kernel with regard to these
patents. One would think that it would make little sense for TomTom to go
into the kernel source and create its own special version of VFAT which
infringes on Microsoft's patents. Of course, embedded systems developers
have been known to do some very strange things, so one cannot take TomTom's
good sense for granted in this situation. So, for the definitive word, we
will refer to Harald
Welte's take on TomTom's kernel:
I have actually reviewed the TomTom kernel sources a number of
times during the last couple of years as part of gpl-compliance
reviews. I can tell you, there is nothing "TomTom specific" in
their FAT FS code. It is the plain fat/msdos/vfat file system like
in every kernel.org kernel.
If TomTom is infringing Microsoft's patents, then everybody who is running
Linux is infringing those patents. This is an attack against Linux; TomTom
has just been given the honor of being the first defendant.
Microsoft's motivation would seem to be clear. The company has tried for
years to sell versions of Windows into the embedded systems market, with
success best described as "modest." Linux is hard to compete against in
these systems; it is highly portable, can be customized to an arbitrary
degree, offers support from multiple vendors, and can be shipped with no
royalty charges. Microsoft would like to take away some of those
advantages by imposing a patent tax on embedded Linux deployments.
Embedded systems vendors cannot miss this message: they can pay licensing
fees, or they can pay legal fees.
The obvious question at this point is: what now?
The VFAT patents may appear to fail the obviousness test; they could also
run into difficulties stemming from the Bilski
decision. These patents are problematic, though: the Public Patent
Foundation tried hard to invalidate these patents in 2004, only to have
by the US patent office in 2006. As a result, there will be a certain
presumption of validity which could prove hard to overcome in court. It
has often been said that attempts to invalidate patents carry risks; what
doesn't kill a patent may well make it stronger.
Your editor would certainly not advise anybody to give up on efforts to
defeat these patents, but the possibility that they could stand must be
The loss of the VFAT filesystem would be painful. It is a poor filesystem,
but it has become a sort of de facto interchange format for
storage-oriented devices. Without VFAT, Linux users would encounter
difficulties working with their digital cameras, cellular telephones, and
music players. Sharing storage devices with Windows systems would become
harder. VFAT would become a technology like MP3: unavailable on many Linux
systems until installed from some third-party repository on the net.
Avoiding this outcome seems desirable. One way would be to defeat these
patents in court. To that end, one can only hope that TomTom will stand up
to this attack and defend its rights. The rest of the industry would be
well advised to consider helping TomTom in this fight. This case, if
fought to its conclusion, will certainly be expensive. But the cost of not
fighting it seems certain to be much higher.
Another way to deal with the VFAT patents would
be to start a serious look for workarounds - a technique which the free
software community does not, yet, make enough use of. Patents tend to be
tightly written, meaning that workarounds are often possible with relatively small
changes. It may well be possible to make changes to the VFAT filesystem
which pass the patent-lawyer test while maintaining interoperability with
Indeed, a suitably clever lawyer might be able to argue that Linux already
operates outside the patent; the claims require that the long filename
include "more than the maximum number of characters that is permissible by
the operating system," something which is clearly not the case on Linux.
Your editor, however, is neither a lawyer nor suitably clever; this kind of
determination will need to be made by others.
At the upcoming Linux
Foundation Collaboration Summit, your editor will be running a panel on
kernel development. Sam Ramji, alas, will be in the other room at that
time, sitting on a panel entitled "Why Can't We All Just Get Along: Linux,
Microsoft & Sun." One can imagine the course this discussion is going
to take; Sun is likely to get off easy. Parts of Microsoft (especially
those represented by Mr. Ramji) have been making friendly noises toward
open source for some time. But actions speak louder than friendly noises,
and this particular action speaks loudly indeed. Parts of Microsoft are
almost certainly sincere about wanting to get along with the Linux
community, but the stronger forces within the company, it seems, are not.
Comments (62 posted)
Ever since last July, when Mark Shuttleworth called on Ubuntu to surpass Mac OS X in desktop
design within two years, Ubuntu mailing lists and blogs have become one of
the main places to go for detailed discussions about GNU/Linux
usability. However, the discussions can become convoluted and acrimonious,
as developers argue the logic of design principles. A case in point is the
discussion of Ubuntu's new notification guidelines on the ubuntu-devel
list over the past two weeks, which quickly turned into a discussion of
whether notifications should be used at all.
The discussion centers around the new guidelines for notification messages,
which typically appear by the notification tray in GNOME. These guidelines
were announced in Mark Shuttleworth's blog entry for February
21. Both the blog and the guidelines include screen shots to
illustrate what they are describing.
The problem is that the now-standard notification bubbles (so-called for
their shape) are easily missed because they disappear after a few seconds,
and they often point to icons in the system tray, which users may find hard to
click. For these reasons, the guidelines call for a reduction in their use,
although acknowledging the possibility that they might still be useful in
Whenever possible, notification bubbles will, in the next Ubuntu
release, be replaced with a notification in an existing window; for instance,
when a web browser has blocked up a popup, the notification could display
in a dialog above the web page, using the browser's built-in notification
system. More radically, when a notification needs user input, but doesn't
need an immediate response — for instance, when a printer is
detected, but the necessary driver is missing — it will be displayed
in an alert box that opens beside the system tray without taking the focus
away from the user's current window.
In cases such as a low battery reading, when a quick response is needed,
the window or alert box will display the basic message, followed by, when the user
clicks it, a dialog, possibly with a different color background. The
guidelines refer to this arrangement as "morphing," and suggest that it
will help prevent the accidental selection of a button when the cursor
moves to the dialog. Why accidental selection is perceived as a problem,
though, is unspecified.
The advantages of the proposed alert boxes is that, unlike notification
bubbles, they remain on the desktop, and provide dialogs that are easier to
click than a system tray icon.
Discussion of these new guidelines quickly followed Shuttleworth's blog
entry, wandering across several threads in ubuntu-devel in February and
March. Some of the discussion called for citations to support a usability
assertion, as when Jordan Mantha told
Mat Tomaszewski of the Canonical design team, the group responsible for the
guidelines, that "'trust us, we have our reasons' is not going to
very convincing to many people."
As discussion continued, it soon became apparent that at least some Ubuntu
designers outside Canonical distrust those employed by the company. For
instance, Scott Kitterman remarked:
The feeling I get from many email and IRC discussions with people
involved in the Canonical [Desktop Experience team] is that they
are so convinced of the correctness of their design that any
disagreement with it must stem from a lack of understanding from
Similarly, Martin Owens complained
that "It's as if the people at Canonical had taken a politics course
and decided to deliberately alienate those people who are not inside of
To such comments, Mat Tomaszewski replied several times, with patience and
enthusiasm for the tasks at hand, while Matthew Paul Thomas, another
Canonical employee, explained in a similar tone that usability efforts were
just getting started, and were expensive enough that "much of the
time we will have to rely on common sense".
At one point, the language became so heated that Mark Shuttleworth intervened
to call one developer's comments "not constructive" — a
rare occurrence on Ubuntu lists compared to those of some projects, due to
of conduct by which developers agree to abide.
However, for the most part, discussion remained civil. Matthew Paul Thomas
the new guidelines, pointing out that:
[A] 22*22-pixel icon in the
could never convey the idea that there are software updates
available to a usefully large proportion of our users, no matter how good
the icon designer was. An actual sentence saying, 'Software updates are
available for this computer' can do a much better job.
Thomas also summarized potential problems with notice bubbles: either they
disappear after a few seconds and can disappear before users notice them,
or else they persist and distract users. In addition, alerts and windows
are easier to use than small, often indistinguishable icons.
By contrast, Lars Wirzenius presented
a case against all notifications, saying flatly that:
are always interruptions. When something new popups up on the screen, it
interrupts my thought and my work, and if I'm 'in the zone' (also known as
'in hack mode,' that interruption may cost about fifteen minutes of
effective work time.
Wirzenius wanted was essential notifications, suggesting that "All
applications should, in my opinion, strive to interrupt the user as little
as possible, especially by default."
Wirzenius' position was soon challenged by other developers in ways that
show some of the considerations necessary in usability design. Chow Loong
Wirzenius' assertion that default settings should be designed for those who
use their computer as a "tool" rather than a
"toy," arguing that the tool users would know how to change
the defaults while the toy users would not.
Similarly, Ted Gould contended
that, since toy users are probably a majority, the defaults should be
settings that they want. In the same post, he also suggests that:
reality is that you want different levels of notifications at different
times. Sometimes an interruption is okay and sometimes it certainly is
not. For instance, someone IMing you 'wanna take a long lunch?' while
you're giving a presentation to your boss. The problem is that it's hard to
detect what people's intentions are.
However, Tomaszewski indicated
that some ability to change levels of notifications would be available via
a "Do not disturb" mode that would block at least some
What made this discussion especially interesting was how it brought out
both the general and specific issues that arise in usability. For instance,
Mathew Paul Thomas responded
to the suggestion that using an application at full-screen size should
disable notifications by pointing out that:
If you're using Ubuntu on
a netbook, for example, you're quite likely to make the current application
full-screen whenever you can — but that doesn't have anything to do
with which notification bubbles you want to see.
Thomas also warned
Developers often think their software is more fascinating to
people than it actually is, which leads them to make the software more
'chatty' than it should be. (The pathological extreme of this can be found
in the Windows Vista
User Experience Guidelines, which seriously recommend that a
'non-critical system event' should display a notification balloon 'once
every 10 minutes if users must resolve within an hour, once every hour if
users must resolve within a day.').
In much the same way, Tomaszewski stated:
[W]e have good reason to believe that persistent indicators only
work for some very specific cases (examples being network connection,
volume, etc.). We are now going through the long and painful process of
carefully defining these cases.
Yet another post, this time by Bruce Cowan, summarized
the problems with any sort of dialog. The sudden appearance of windows and
alerts, Cowan suggested, is confusing, and could make users worry that a
piece of malware has started an application. In addition, too many dialogs
could frustrate users, to the point that some disable them altogether, so
that over-use of the system could defeat the entire purpose of providing
timely warnings. As for the changes in the new guidelines, Cowan suggested
that they may annoy experienced users who see little wrong with
Whether these discussions will have any effect on the Ubuntu Design or
Desktop Experience Team seems uncertain, since the guidelines are already
being used in alpha versions of the upcoming Jaunty release. All the same,
they are the sort of discussions that Ubuntu developers are likely to be
having for the next eighteen months as they try to realize Shuttleworth's
goal of increased usability, especially in the absence of hard data to show
what designs are most usable. They are likely, too, to have them again, as
they attempt to have their changes accepted upstream by projects like
GNOME. However, for others, they show the punctilious but necessary
considerations that usability generally involve — considerations that
many free and open source software projects are only just starting to face.
Comments (42 posted)
Page editor: Jonathan Corbet
Next page: Security>>