User: Password:
|
|
Subscribe / Log in / New account

How (not) to brick the Android Developer Phone

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Jonathan Corbet
February 18, 2009
Your editor's adventure with the Android Developer Phone (ADP1) began just before the end of the year. This phone, remember, has the nearly unique selling point that it is lacking any sort of lockdown feature. It will happily run any software which is fed to it, from the kernel on up. It thus brings the promise of free software to a market which has traditionally gone out of its way to avoid enabling any sort of freedom. It's actually possible to control the software we run on our phones - but only if we buy the right phone.

The path to exercising this freedom is long and poorly documented, though. Eventually somebody will certainly pull together a definitive resource for developers wanting to hack on their Android phones; until then, one is left digging through a long series of web sites and forums (a few of which are listed below). This article will not be that resource, but, hopefully, it can help to point interested people in the right direction. Please note that this article assumes that you have an ADP1 phone; if you have a locked-down G1 you can still participate in all of the fun and games that follow, but you will need to root the phone first.

The first stop, unfortunately, is the decidedly non-free Android SDK. Actually, this package is only truly mandatory for those wanting to build Android applications of their own. But it contains a pre-built version of the Android Debug Bridge (adb) tool, which is essential for working with the phone over a USB connection. With adb, one can connect to a shell running on the phone, move files back and forth, forward network ports to and from the phone, and more. Yes, one can run a shell directly on the device using the terminal emulator application, but life is certainly much easier when one can use a real keyboard.

Note that it may be necessary to either (1) run adb as root, or (2) play with your udev setup to be able to access the phone via USB.

Putting new software onto the phone involves flashing its NVRAM. There are six partitions on the onboard flash:

    dev:    size   erasesize  name
    mtd0: 00040000 00020000 "misc"
    mtd1: 00500000 00020000 "recovery"
    mtd2: 00280000 00020000 "boot"
    mtd3: 04380000 00020000 "system"
    mtd4: 04380000 00020000 "cache"
    mtd5: 04ac0000 00020000 "userdata"

Details about these partitions can be found on this page. Most of them will be fairly obvious in purpose. The "recovery" partition holds a recovery image which can be used to un-brick the phone. In "boot" is the initial system image, while "system" is the root filesystem. Application settings and such go into "userdata". With any luck at all, it should be possible to put a new system onto the phone by flashing only the "boot" and "system" partitions, leaving settings and such in place.

First, though, comes that sweaty-palms moment when one realizes that one is about to overwrite the operating software on an expensive new toy. A fairly nice new toy that, mostly likely, has become an important working tool. The idea of turning this nice device into an expensive brick lacks appeal. It might be different if the second-generation Android devices were available; then, at least, one could rationalize an update disaster as a celestial sign that it's time to get a newer phone. In the absence of such an ulterior motive, your editor stepped back from the brink and pondered ways to recover from a failed update.

Everybody should be able to run vi on their phone (though emacs appears to be a bit too much to hope for). One method your editor has seen recommended is to simply make copies of the various /dev/mtd/mtd? devices, then use adb to lift those copies off the phone. The system running on the phone has a rather minimal command set, so this copying must be done using cat and shell redirection operators. This experience gives a quick thrill, as if one were reliving the very earliest days of Unix before advanced commands like cp had been invented, but said thrill is quick indeed. Thereafter, one usually wants to go out and install busybox on the device. After making a few strategic symbolic links, one will have something that looks a lot more like an ordinary Linux shell environment. Everybody should be able to run vi on their phone (though emacs appears to be a bit too much to hope for).

Back to backups: an alternative is to use the nandroid script. With nandroid, a simple command will back up all of the useful partitions on the device in a way which lets them be quickly restored. Unfortunately, though, nandroid will not work with a stock phone. At a minimum, one must install busybox, then make links for commands like nc, tar, and md5sum. Alternatively, one can install the modified recovery image from the amazingly productive "JesusFreke," then back up the phone while it is in recovery mode. Either way, one will, once again, end up with a set of image files containing copies of the phone's flash partitions.

So what does one do with these image files? The key tool here is fastboot, a command-line tool which runs on a Linux-based host system. With fastboot, one can flash one or more partitions to a USB-connected phone, then reboot into the new code. First, though, one must know the secret handshake: power up the phone while holding down the camera button, connect the USB cable, then hit the "back" button until the display reads "fastboot." Needless to say, the manual that came with the ADP1 did not mention this little detail.

Of course, said "manual" is a single slip of paper showing how to insert the battery.

Once one is convinced of one's ability to recover from a disaster, it's time to try to put some new software onto the phone. If you have built the Android platform from source (a process which will be addressed in the next installment), the result will be new "boot" and "system" images which can be flashed to the phone using fastboot. System images built by others can also take that form, but the more common approach is to package the whole thing up into a Zip file. In such cases, the recipe is as follows:

  • Using adb, put the update image onto the SD card on the phone (mounted under /sdcard) as update.zip.

  • Reboot the phone into recovery mode (secret handshake: hold down the "home" key while booting).

  • Press alt l, followed by alt s. Note that, unlike ordinary ADP1/G1 keyboard operation, you need to actually hold down the "alt" key while pressing the associated letter.

This sequence will cause the phone to rewrite its software with the image found in the update.zip file. Once the process is complete, hitting the "home" and "back" buttons together will reboot the phone into the new image.

So, what might one install via this method? The set of modified images provided by JesusFreke are a good place to start. The JFv1.31 image makes a lot of things work more nicely; it includes busybox with a set of useful links, a fancier recovery image with built-in backup capability, a version of su which asks the user for confirmation (and which, thus, should be harder to exploit from an evil application), and more. Also worth noting is that the JF images disable any over-the-air updates. Such updates should not be happening with an ADP1 phone in any case, but, when one has control over one's own phone, there is no reason to allow outside agencies to drop new software into it.

Rather more fun can be had by going to the JFv1.43 image. This version includes an update from Android, which is said to fix a number of small issues and improve battery life. It adds a voice calling capability which was notably lacking in the original Android distribution. Your editor's first attempt, "call home," was turned into "call mom" though; Google does not appear (yet) to have achieved a level of omniscience sufficient to know that those two have not been synonymous for some years now. Also added is a voice search mechanism. But that's not all: this update includes the multitouch functionality that Google left out; the "pinch" gesture now zooms web pages in and out. Other applications have not yet been enhanced to use multitouch, yet.

Arguably even nicer than multitouch at this point is the new "autorotate" setting in the browser. The ADP1 can report its orientation to an application, but almost no applications make use of that information. So, on a stock ADP1, using the browser in landscape mode requires opening the keyboard. With autorotate turned on, the browser senses when the phone has been turned and adjusts the display accordingly. It's one of those little features which should have been there from the outset.

And that, of course, gets to the heart of why an open phone is such a nice thing to have. We're no longer dependent on the manufacturer to get everything right, and we're no longer dependent on wireless carriers to hold off from crippling our devices. We bought the hardware, and we wrote the software. We are well within our rights to change how it all works - even if we want to do something crazy like install Debian over Android. It is unfortunate that, at this time, so few devices afford this kind of freedom; ADP1 and OpenMoko appear to be about the only options. With any luck at all, awareness of the value of this freedom will spread over time, and vendors will find that their customers will settle for nothing less.

Of course, real freedom doesn't stop at the ability to install software images created by others. The next installment in this series will start to delve into the process of generating a new system image from source. Among other things, your editor intends to take the "cupcake" development version - which includes, among other things, the much-requested on-screen keyboard feature - for a spin. Stay tuned.

Resources. Information about working with Android is spread around the net; here are a few useful places your editor has found:

  • There is, of course, good information to be found at source.android.com.

  • developer.android.com is the source for the software development kit and related information.

  • The xda-developers site is a repository for vast amounts of useful - if noisy and slowly-served - information. In particular, the Dream Android development forums seem to be the primary gathering point for people hacking on this platform.

  • Some information - notably new pre-built image announcements - can be found on andblogs.net.


(Log in to post comments)

How (not) to brick the Android Developer Phone

Posted Feb 18, 2009 21:00 UTC (Wed) by literfizzer (subscriber, #31274) [Link]

Sounds like fun. But is it really necessary to reflash the bootloader when installing a new firmware image? This is usually unnecessary and is the one thing that can really irrevocably brick the phone if it goes wrong.

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 3:11 UTC (Thu) by corvus (guest, #82) [Link]

It's not necessary to reflash the bootloader to use a new system image, and, as you suggest, not a good idea. None of the partitions mentioned in the article contain the bootloader, including the potentially confusingly named "boot" partition. Instead it contains what the bootloader (or SPL -- second program loader) boots.

If your phone already has a fastboot compatible SPL (the ADP1 mentioned in the article does), there is no need to change the bootloader, and you can flash newly-built system images, or backups of your old images at will without (much) fear of bricking your phone. When I want to try a new image I've built, I use nandroid to back up my phone in its current state, then fastboot to flash the image, and if it's unsatisfactory, use fastboot to flash by nandroid backups back.

Typically, part of the process of liberating a G1 is to replace the SPL with a fastboot-enabled version.

How (not) to brick the Android Developer Phone

Posted Feb 20, 2009 1:01 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

So you can update the SPL? Does that mean you can brick the machine beyond recovery by any means mentioned in the article by doing that poorly?

How (not) to brick the Android Developer Phone

Posted Jun 26, 2009 8:17 UTC (Fri) by Pinin (guest, #59306) [Link]

Sorry to bump an old thread, but I just can't help to answer this ... YES !
Yes you can brick your ADP1 so badly, but there is a way to recover though.
And I know because I have been there.
I recovered by flashing a DREAIMG.nbh for a comercial T-Mobile G1 and then I had to use the corresponding trick to root the phone, update the SPL again and so on. If anybody knows a better way to solve the problem, I wouldn't mind to know, my ADP is in big danger of having trouble again.

How (not) to brick the Android Developer Phone

Posted Feb 18, 2009 21:11 UTC (Wed) by Thue (subscriber, #14277) [Link]

Do anyone know how to go about buying an unlocked android phone in Denmark, and what it will cost?

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 9:33 UTC (Thu) by fb (subscriber, #53265) [Link]

I have seen the numbers for The Netherlands, and it was close to 450euros.

IIRC Google will include the import taxes in your price.

People have been able to turn T-Mobile branded phones into a Dev phone, but it probably involves taking lots of risks. But that only works with 'root access', and this hasn't yet been achieved for European G1's.

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 13:20 UTC (Thu) by hanwen (subscriber, #4329) [Link]

go to http://www.android.com/market/ , sign up as developer (US$ 25), and order the phone ($ 400 ex shipping and tax).

Nonfree SDK?

Posted Feb 18, 2009 21:42 UTC (Wed) by teferi (subscriber, #55421) [Link]

IIRC, the SDK isn't actually nonfree - it should be possible to build it from the Android source tree.

Nonfree SDK?

Posted Feb 18, 2009 21:51 UTC (Wed) by corbet (editor, #1) [Link]

Here's the SDK terms and conditions. I wouldn't call them DFSG-compliant...

Nonfree SDK?

Posted Feb 19, 2009 0:05 UTC (Thu) by teferi (subscriber, #55421) [Link]

The stuff in http://android.git.kernel.org/?p=platform/development.git;... sure seems to be Apache-licensed. Hmm.

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 0:15 UTC (Thu) by TxtEdMacs (guest, #5983) [Link]

Perhaps a dumb question, why do two of the partitions have the same address?

mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"

Which does not seem to be a typo, since that's exactly what is shown in the referenced link: http://forum.xda-developers.com/showthread.php?t=443994

What am I missing?

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 1:29 UTC (Thu) by i3839 (guest, #31386) [Link]

04380000 is the partition size, not its address.

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 1:39 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

With any luck at all, awareness of the value of this freedom will spread over time, and vendors will find that their customers will settle for nothing less.

The whole concept of open hardware/software in the mobile arena seems quite new. Let's hope that this is a winning design from a hardware, software, and legal perspective.

...but you will need to root the phone first.

Careful, there. "Root" (as a verb) takes on a whole different meaning in various non-American English-speaking cultures.

The idea of turning this nice device into an expensive brick lacks appeal.

I nominate the above for The Subdued Yet Profound Statement of the year Award. ;)

I'm done being silly, now. Many thanks to our editor for his research, findings, and commentary. Must be fun to play with such a nifty toy!

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 22:07 UTC (Thu) by man_ls (guest, #15091) [Link]

Careful, there. "Root" (as a verb) takes on a whole different meaning in various non-American English-speaking cultures.
Such as? They don't come up in wordreference. At least not as a transitive verb ("root something", as opposed to "root somewhere" or "root for someone").

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 22:38 UTC (Thu) by mbg (subscriber, #4940) [Link]

How (not) to brick the Android Developer Phone

Posted Feb 20, 2009 7:25 UTC (Fri) by man_ls (guest, #15091) [Link]

Thanks. In a sense this new meaning describes our editor's fears perfectly.

Some way still to be able to use the freedoms...

Posted Feb 19, 2009 7:39 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

I might be wrong, but coming from the Openmoko land, I feel like the author is only in the very beginning of realizing how to use a free phone :) Why installing Debian is "crazy"? Debian is the universal operating system, as is said, and Debian can be used for phone functionality without a hitch currently on Openmoko. Freesmartphone.org is generating a basis of phone/PIM functionality that can be built upon by any distribution. The fact that there are missing parts on Android phones currently when using non-Android software does not mean replacing Android would be crazy in the long run.

I do hope Android phones would soon get their phone functionality usage and power management generalized to the level that people could actually start exercising their freedoms. I also hope the author could shed a light on any developments on these fronts:

- Is someone trying to reproduce the current Android software power management system in a more general (and simple) way? Suspend working while GSM is on, what's the battery life when using eg. Debian?
- Are all the kernel patches / drivers going to the mainline kernel?
- Is there anything stirring to implement ADP1 support in http://freesmartphone.org/ ?
- Can you currently make phone calls when using non-Android software somehow? Any UIs yet?

I am not really interested in a phone that is hackable but by default only really usable with partially non-free software stack, so therefore (as an user) I am interested in the development of completely free software stacks. Also even though there may be a free Android distribution, I'd rather go for a more general one that doesn't need recoding all the software. Ie. GTK, Qt support would be nice.

What is not free in Adroid stack?

Posted Feb 19, 2009 10:19 UTC (Thu) by khim (subscriber, #9252) [Link]

I am not really interested in a phone that is hackable but by default only really usable with partially non-free software stack, so therefore (as an user) I am interested in the development of completely free software stacks.

AFAIK the only non-free parts in Android software stack are codecs - and these are not free by patent reason. Other non-free parts (like GMail client or YouTube client) are completely optional. And it's way easier to replace codecs with free ones (where legal) than to create the whole new stack. And if you'll compare number of phones with Android today with all other phones with "free software stacks"...

Usage of G1 without Android is certainly possible but unfeasible...

Great article!

Posted Feb 19, 2009 8:54 UTC (Thu) by ftclausen (guest, #23228) [Link]

Hello,

I totally agree that attaining the freedom to run what we want on our phone is important. And, as tajyrink pointed out, Android and the ADP1 have some "freedom issues" (for lack of a better way of putting it) I think it is still a good starting point.

I myself use an OpenMoko Neo Freerunner running QTextended. This is working reasonable well as a daily phone (since my last one is being used by my girlfriend after her phone broke) but once the Openmoko FSO based images are stable then I will give them a try. Also, the Openmoko Wiki is a great resource.

I also ran Android on my Neo but I could not answer calls since Android assumed the presence of a physical button - which was not there. However, I will try Android again once the Neo version has matured a bit more.

All in all the fact that we can SSH into our phones is already a major milestone.

Happy adventuring!

Openmoko already kind of there

Posted Feb 19, 2009 10:50 UTC (Thu) by madhatter (subscriber, #4665) [Link]

i know "me too"s are by definition grim, but as another person happily using an openmoko as his daily phone, i'm a bit sad reading this excellent analysis of all the problems that freely using the android presents while thinking "we've solved that... we've solved that... we've solved that" about the 'moko:

> the decidedly non-free Android SDK ... contains [the] (adb) tool, which
> is essential for working with the phone over a USB connection. With adb,
> one can connect to a shell running on the phone
ssh
> move files back and forth
scp / rsync over ssh
> forward network ports to and from the phone
iptables

> The idea of turning this nice device into an expensive brick lacks appeal
two boot firmwares, one writeable and one not, so the latter can always be used to rescue the freerunner from bad overwrite of the former (does *not* apply to neo 1973).

backups? dfu-util and/or mkfs.jffs2

> Of course, said "manual" is a single slip of paper
the openmoko wiki is a bit chaotic, but there's a lot of stuff in it. more by the day, i find.

> The ADP1 can report its orientation to an application, but almost no
> applications make use of that information.
openmookow (really!), and many others

i'm *glad* there are more and more free GSM devices; many is good. a plurality of free OSes and dev environments is good. but it makes me a little sad that so much enthusiasm is being put into this platform which doesn't seem to be designed primarily for freedom, when there are designed-free platforms that could do with being better still.

doubtless there are good things about the G1. but it's not a great product merely because google made it and apple didn't.

(disclaimer: i have no commercial connection with any part of openmoko except that i bought two full-price phones from a distributor.)

How (not) to brick the Android Developer Phone

Posted Feb 19, 2009 13:10 UTC (Thu) by appie (guest, #34002) [Link]

Now if only we could get rid of the difference between data and data, oh sorry, "voice" and "data" we could happily start using SIP and enjoy all the technical merits it would bring us instead of the convoluted schemes the operators are dreaming up to be able to force us into Their Way.
But that will only happen at gun point I'm afraid :(

How (not) to brick the Android Developer Phone

Posted Feb 26, 2009 11:08 UTC (Thu) by muwlgr (guest, #35359) [Link]

Just have a look at

http://www.macworld.com/article/139045/2009/02/google_g1....

"People who bought an unlocked version of the Android G1 phone are no longer allowed to download new paid applications from the Market, after a change Google made late last week."

And so on.


Copyright © 2009, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds