• ./adb pull /sdcard/download/fennec.apk ~/fennec.apk
• ./adb install ~/fennec.apk

Dear Mozilla, great idea directing folks to the right download automatically, but please take this case into consideration. Lots of folks on AT&T devices who can’t install directly. Or, alternatively, AT&T could stop being idiots. Slim chance of that though.

There’s plenty of info out there about replacing the boot logo and what the files do. Here’s how to get it up and running through:

1. Download the pirate boot animation zip file to your system
2. Remount the system partition read-write: adb shell mount -o rw,remount /dev/block/mtdblock3 /system
3. Push the file across to your device: adb push pirate_bootanimation.zip /system/media/bootanimation.zip

That’s it, reboot and enjoy! If you want to poke around and change it, it should be pretty easy. There’s a writeup of what the contents of the bootanimation.zip are, which is very useful. Supposedly, also, the zip needs to be uncompressed to work. But that just means setting compression level to 0 when you run zip. This is the command I use on my OS X machine: zip -0 pirate_bootanimation.zip desc.txt part0/boot_00003.png”. That should make it easy to swap in any other picture to customize.

Finally tonight I took some time to actually search around some and try to find “the right info” to get a rooted version of a custom firmware onto the device. The wiki area of the Cyanogenmod site is definitely the right place to go. They have some “Full Update Guides” linked from the front page which walk through step by step the different processes you need to go through, including a process for installing a Cyanogenmod firmware starting from a stock Nexus One. Exactly what I was looking for. It walks you through all the complementary processes too, like unlocking the bootloader and installing a recovery image.

I went with the stable Cyanogenmod release, so I’m slightly downgraded in terms of the Google release this bases off of. But there’s a bunch of capabilities in the new recovery image as well as root access to weigh that against… and right now root access is definitely winning.

1. Follow the instructions to download and build Android from source. Follow the whole thing (I had to create a case-sensitive disk image and all), including the actual build step. Otherwise you won’t have the libraries necessary and agcc will error out when you try to run it.
2. Add the prebuilt/darwin-x86/toolchain/arm-eabi-4.2.1/bin subdirectory of where ever you built the source to your PATH, add it to your .bash_profile if you want.
3. Download the agcc wrapper script, put it somewhere in your path, and make it executable.

Now you should be ready to compile a program and download it to your phone. This was my test app:

#include <stdio.h>

int main( int argc, char **argv ) {
  printf("Hello from Droid Hacks!\n");
  return 0;
}

And you should be able to compile it with “agcc hello.c -o hello” and end up with a hello executable:

~ > agcc hello.c -o hello
~ > file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
~ >

And you can move the file across to the phone and run it. You’ll have to make a directory to push it into. The sdcard is marked as noexec, so you can’t run stuff from there. And the data directory has more restrictive permissions. So you’ll have to su and create a directory on the data partition, and relax the perms on that directory:

~ > adb shell
$ su
# mkdir /data/droidtest
# chmod 777 /data/droidtest
# exit
$ exit
~ > adb push hello /data/droidtest
418 KB/s (6747 bytes in 0.015s)
~ > adb shell
$ cd /data/droidtest
$ ls -l
-rwxrwxrwx shell    shell        6747 2009-05-27 08:56 hello
$ ./hello
Hello from Droid Hacks!
$

And of course you can run the same thing from the terminal on your device as well:

• mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
• cd /system/bin
• cat sh > usu
• chmod 4755 usu

Some of the instructions I found online suggested just calling the new binary su, but I was concerned about that overriding the default su depending on what path is getting used. So I just created a whole name “user su” which won’t reject the handset user when I try to change to root: