[OT?] Android phones

[D. Hugh Redelmeier]

| From: Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>

| - They need the phones certified by FCC (US)/DOC (Canada)

I thought that all phones now had one hidden processor ("baseband") to
do the radio things that the FCC and DOC care about and that Android
runs on a separate, non-critical processor.

As such, I don't think that the FCC and DOC care about Android releases.

| - Phones need to be tested by the carrier

But new Android releases shouldn't need too stringent testing by the
carrier.

The real work would be to drag forward their customization (cynical
view: their crippling).

Annecdote: when we (DGP at U of T) first got UNIX in January 1975, we
hacked on it a lot, improving and fixing it.  About the third time we
had to port our changes to new releases, we got very conservative
about what changes were worth the effort.

So: maybe the flurry of Android releases will have the salutory effect
of making verdor value-subtracting painful to the perpetrators.

| - They need to negotiate pricing and such with sources

Naive question: why should there be a pricing of a firmware update?

| - They need to arrange the logistics of deliveries of phones, and if
| they're aggressively hawking "latest and greatest," they're fighting
| with other carriers that would like to be first instead

Logistics of firmware delivery are not too bad.  Assuming the
procedures are designed to never brick the device.  It can be done in
the consumers' hands.

| - They need to set up all the "branding stuff" that is *always* done
| with phones, including:
|  - Setting up custom firmware with logos and such
|  - Having the hardware vendors "paint on" (or silkscreen, or whatever)
| logos onto the plastic

Do you really have to paint on the firmware version?  Damn, I've never
done that as part of the firmware update process of the devices around
here.

| There's enough work involved in this that it's a risky endeavor to ask
| to get some software release pushed in that was only released by
| Google 8 weeks ago.

Yes, 8 weeks is a short time.  But if releases are light weight, it
might be managable.

You know that we've achieved appliance status when it is recognized
that the main cost of upgrades is in re-educating the users, not in
the technical details.

| Few OSS projects attempt remotely similar...  Think about release rates...

I don't know enough about how big a deal an Android release is.  Is it
really comparable to a full Linux distro release?

I guess it comes down to articulation: how much does an Android change
affect downstream code, how much does it affect the user.  On one end
of the scale, bug fixes are generally benign or beneficial (kind of by
definition).

I don't actually understand, on a philosophical level, what a Linux
distro release really is.  I certainly do on a practical level and I'm
not really sure that they amount to an optimal organization of change.


I like my Nokia n800 (a tablet, not a phone).  But I really hate that
Nokia seems to support these platforms for a year or so then abandon
support for them (770, n800, n810, n900).

If Android updates continue to flow to old phones, that would be a
real feather in the ecosystem's cap.  That really depends on the
incentives for the relevant players.  OpenMoko, if it succeeded, ought
to have accomplished that: the OpenMoko customer is the owner of the
phone, not the pusher.