This page continues to be very popular among readers. The techniques described below rely upon a kernel bug that has long since been patched, but if you are able to downgrade your phone to an earlier version this process remains a very easy way to root your phone.

Amazon Wireless has some great deals on newer android phones (A Samsung Vibrant for as low as $39 is a pretty good deal – that phone hauls butt) – and they are all easily rootable too (well, not quite one-click easy, but still pretty easy). Just about any of the newer phones shipping with 2.1 or 2.2 will blow the doors off of the older phones that can be downgraded to work with this one-click root bug, so I would recommend checking them out at least to see what you can get for cheap these days. If any people actually buy phones from clicking that link, I’ll be motivated to write some more easy-to-follow instructions on how to root the newer phones on the market and possibly even work with Zinx on some more easy-to-use rooting tools.

Now, that being said – while you wait for your new phone to ship, there’s no harm in squeezing a bit more life out of an old phone or one that you just inherited from someone else upgrading to the latest and greatest… and for that – you can read on and use the techniques documented here.

As is customary with these kind of posts, some disclaimers:

1. This could be dangerous.
2. This should only be used if you know what you are doing.
3. Although this technique will work for any currently shipping android phone, this specific APK will works easiest with phones that are compatible with cyanogen’s 1.4 recovery image for the HTC Dream/Magic (32B).. There are instructions posted below for how to download a recovery.img that will work for other phones to your SD card, and how to use this apk to root those phones as well – it’s just not one-click… it’s more like some typing and 1-click so it might take you 30 seconds longer to do)

Now, some credit:

1. Zinx did all the work on this

UPDATE: The “Recovery Flasher” is no longer in the market. This is entirely understandable and we as a community have no real right to be upset about this (their market, their rules – and after inspecting it they determined that the app violates them). So… Consider yourself lucky if you were one of the several thousand people who got it before it was taken down – and if not… there are plenty of mirrors to get it from posted here. (Android by design allows you to install applications from a variety of locations – you aren’t locked down to just one provider like on some fruity phones). So please don’t have a knee-jerk reaction and get mad at Google for this – they are still very much hacker-friendly (just search the market for applications that only work on rooted phones and you’ll realize that they are pretty laissez-faire in the market).

Flashing your recovery image:

Although the exploit itself can be used to execute anything as root, the prepackaged APK is designed to flash your recovery image with an updated one that allows installing modified updates signed with a publicly available key The reason for this is pretty simple: It’s the easiest way to enable you to install some modified image. It also enables you to use nandroid to backup (and restore) your entire phone to your sd card, and basically gives you what you need to be one of the cool kids and install custom android roms at will

Install the APK

The application has been uploaded to the market, and that’s the fastest place to get it from. Open up the Market and search for “Recovery Flasher” and download it from there,

In your settings, under software, tell it to allow untrusted sources. (necessary since the APK isn’t available in the market). Then, from the browser on your phone download the “recovery flasher 0.1 APK” from here: http://g1files.webs.com/Zinx/flashrec-20090815.apk Install it… and open it up.

Download from one of these mirrors

• http://g1files.webs.com/Zinx/flashrec-20090815.apk
• http://zenthought.org/content/project/flashrec

It looks like this:

From here:

1. click on “backup recovery image”
2. click on “Flash Cyanogen Recovery 1.4″

(in mine there is the option to restore my previous one since I already backed that thing up)

Test that it worked

Power your phone down. Reboot into “recovery mode”. On all phones I’m aware of, you do this by holding down “Home” and “Power” when turning it on. When you see something like this:

Original links:

If my blog goes down, these links are the original source for the files:
http://zenthought.org/content/project/flashrec

Mirrors:
http://g1files.webs.com/Zinx/android-root-20090816.tar.gz
http://g1files.webs.com/Zinx/flashrec-20090815.apk
http://g1files.webs.com/Zinx/flashrec-20090815.tar.gz

Update: More detailed instructions

I have personally used this apk on a T-mobile US G1 running stock CRC1, and a T-mobile myTouch 3g running stock software. Both of them worked flawlessly and were done in matter of seconds. I’ve seen a few threads with people making accusations that this is a trojan or that it doesn’t work… etc.

Regarding the possible ‘trojan’ nature

It’s wise to be skeptical. That’s why the source code is provided and has been since this post was first placed. If you want to be skeptical, that’s fine – download the source, inspect it, build it yourself, and apply it… You would be wise to rely on a brave friend to test it out and verify it works, but I would hold off on applying any security updates that come down the pipe if you want to use this method to get on the modified-image train (I’m almost positive the next update will close this hole)

By now there should be enough evidence to support the fact that this is not a malicious app – but you always have the right to remain skeptical

What you get when you are done

When you are done, you just have the tools to flash modified builds. Because it will run on both HTC 32B Sapphires (T-mobile myTouch 3g, Google Ion, etc) and HTC Dreams (G1, ADP1, etc) I recommend using Cyanogen version 3.9.11.2 – which is an experimental build which has some cool donut features like device-wide searching (which is really really cool to use)

Once you get to the recovery console, first backup your phone using nandroid backup. This will help you in case you flash an image that for some reason doesn’t work – at least you can restore to what you have now. (boot back into recovery, and choose “restore from backup”)

To prepare for rooting, download this file: http://n0rp.chemlab.org/android/experimental/update-cm-3.9.11.2-signed.zip and put it on your sdcard at the root level (i.e. the very top of the sdcard – so if you are in a GUI desktop – just drag the zip file and drop it onto the icon of the sdcard and it will be at the root level)

BEFORE booting into recovery mode

• Have a modified ROM ready to load of your choice. (i.e. the update-cm.3.9.11.2-signed.zip) on your SD card
• Be prepared for the awesomeness you are about to unleash
• Actually flash the recovery image using the recovery flasher apk and following the above instructions

To Boot into recovery mode

1. Power down phone
2. Hold down “Home” and “Power” simultaneously for a few seconds (you can release them once it turns on)
3. Verify that the image matches my screenshot above

Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

This game is one we have come accustomed to playing, and one that is annoying each time we have to play it. The phones download the update from a URL on a google server, and once we know that URL, we can download the update manually and apply it from the SD Card  - or pass it off to the modding community to build a new and better version of it.

There are two parameters passed into the update service that are unique to each device, the IMEI and the device serial number. With the help of a few other people (most notably, Saurik for doing the legwork last update go-round and getting the initial work done)

Here’s theT-mobile USA OTA update polling script

To use it, download it and run it like this:

sh ota-check.sh -sn YOUR_SN_HERE -imei YOUR_IMEI_HERE -sleep NUMBER_OF_SECONDS_TO_SLEEP


If you already got the update, it would be particularly interesting for you to try to run this script with your SN and IMEI. In theory, you should get the URL again – although this hasn’t been the case in the past for some reason (maybe once you checkin on the new version they disable you getting the update again? who knows why and how they work their craziness)

You can get your IMEI from your phone:

• “About the Phone” in the settings menus.

You can get your SN from the phone terminal:

• getprop | grep serial (in the terminal emulator or from adb shell)
• adb devices (I think this shows the SN of the phone, please verify)

If you get a URL, please post it in the comments. I’ll see to it gets passed on quickly.

Luke Hutchison (note to people trying to recruit him for jobs… that is Hutchison, not Hutchinson) has done some tremendous work moving things forward by both explaining the limitations of multitouch and also laying the groundwork for a clever hack to enable basic operations such as two-finger zooming in normal android applications.

You can see his post about the multitouch g1 browser, or watch the video here: (which has a nice catchy tune behind it)
Multitouch zooming on the G1

Two-finger zooming in the browser is a major feature that up until now is only present on the iPhone. As of today, this feature can now be present on anyone’s G1. (So, for those keeping score… the G1 has copy & paste, MMS, and now if you want – a browser you can zoom with using gestures)

In order to apply this to your phone, you will need to get root access to your phone. The best instructions for this are found on the unofficial android wiki. (It is worth noting that once you do this, you will no longer receive updates from T-mobile… but given the fact that any update from T-mobile would almost certainly NOT include this multitouch version of the browser [even though they could easily include it for the G1 since the code is all released])

I’ve been using this for a day or two and it’s nice. Technique is important – you need to be aware that it wont really know what to do with your fingers if you get them too close – so don’t start your zoom motion with both fingers touching and expect it to work well – keep them about an inch or an inch-and-a-half apart at the minimum and it works pretty well.

There is also an option (turned off by default) added to the browser to enable autorotate in the browser. Both of those together are nice.

Go get your files at the xda forums or on the android-dls forums

So, once that is in place, you can flash an image like this one:

My custom Android boot screen (click to DL)

You can then download and use this bash script to flash your G1 boot screen – which requires the following things be in your path:

1. convert (command line for Image Magick)
2. rgb2565 tool (part of android open source build)
3. fastboot (also part of open source build)

Here is the contents of the bash script:


#!/bin/bash
#
# Author: RyeBrye (Ryan Gardner)
# http://ryebrye.com/blog/
# License: Quad-license: GPL / LGPL / BSD / Apache. Pick whichever one you want!
#
# Special thanks to Disconnect and bgupta for their work towards this, and Google / Brian Swetland for
# making such a cool tool as fastboot
#
# This script converts an input image into a rgb565 file that you will flash to your phone. You should
# boot your phone into fastboot mode and run this. (power off phone, then hold down the back
# button and the power button to load into the bootloader. on a hacked G1, you should see the
# skateboarding android image and the text "FASTBOOT" on the phone)
#
#
# Tested input files that work: PNG, or BMP (others will probably work as well)
#
# This script is for the T-Mobile G1 that has a fastboot bootloader flashed onto it,
# or a Dev Phone.
#
# Requires: Image Magick to be installed and in your path (so the convert command works)
# Requires: rbg2565 to be installed and in your path (built as part of the android source build)
# Requires: fastboot to be installed and in your path (build at part of the android source build)
#
# useage: ./splashimage.sh inputimage.png
# results: will flash your splash image, and reboot your phone so you can see your handiwork!
#
#
#
echo "Converting input image to rgb888 raw (saving in temp directory)"

#checking size
eval $(stat -s /tmp/splash.raw565)
if [ "$st_size" == "307200" ]; then
echo "Flashing splash image to phone..."
fastboot flash splash1 /tmp/splash.raw565
echo "Rebooting phone..."
fastboot reboot
echo "Cleaning up temp files..."
rm /tmp/splash.raw
rm /tmp/splash.raw565
else
echo "File was not the expected size. Make sure you are using an 8-bit 320x480 PNG as the original source."
fi


Suggested improvements are welcome. I’m open to hosting the script on the wiki to allow for easy changes to it by interested people. Right now it’s pretty basic, but it works.

Coming from the realm of java web development, I am used to having good tools that automate all the mundane parts of the process. In many cases, most of the data persistence layer of an app is fairly routine… Once you know what the fields in your data objects look like, the rest of the layer is basically spelled out for you… If you have a bean that stores a bunch of strings, you will have a table that stores a bunch of strings… etc.

If you wanted to write out your data structure in shorthand to give to another programmer who would work on that layer for you, you could easily write it out like this:

Entity Person {
String FirstName
String LastName
Date birthdate
@VitalStats vitalStats

Service PersonService {
set getPersonByFirstName(String firstName) throws PersonNotFoundException
set findPerson (firstName, lastName)
}
}
ValueObject VitalStats {
Float weight
int heightInInches
int waistSize
...
}

From that basic description of the data layer, another programmer could easily create for you code that would handle your model and give you an easy iterface to work with it. What is even nicer, however, is that the other programmer doesn’t have to be a human – a properly written tool can take that simple description and also write all the code for you.

One project I have worked with before is Fornax Sculptor – (the domain-specific language in my example is strongly based on sculptor’s DSL) – they in turn build on top of Open ArchitectureWare and integrate their generation solution within the popular java build-tool Maven.

To build a code generation tool to simplify the model layer of an android app would not be too tough. Here is what I was thinking it could provide relatively easily:

• Generate the db adapter, along with the necessary create statements
• Generate simple
  beans to transfer data
• Generate a basic service layer that the rest of the application talks to to get / save data

If anyone has any other thoughts on what kind of things are basically just braindead work once the data model is defined, let me know.

Instructions:

If you want to build your own kernel with the char device for multitouch enabled:

1. Apply the patch to the synaptics touchscreen driver file.
2. Build a new kernel with that modified version in it.
3. Build a new boot.img using that kernel
4. Flash the kernel on the G1 with the new boot.img

If you don’t want to build your own kernel:

• Just copy the boot.img over to your sdcard and then:
  flash_image boot /sdcard/boot.img

5. Reboot the phone

Once the phone reboots, you need to create the device node for it to be able to read it.

It’s easiest to do this from your machine:
adb shell busybox mknod /dev/tsout c 249 0

To test if this works, cat /dev/tsout on the device while you are touching the screen.

Next, build and install the multipoc app from your eclipse build, and install it.

The proof-of-concept app is EXTREMELY rough. If you make significant improvements to things, let me know and I’ll update the files here.

The multitouch proof-of-concept java is based heavily on Google’s fingerpaint program.

Rather than go the proper route, where the multiple finger events would get pushed up from the touchscreen driver and into the java layer where the android applications live and play – another #android member (ionstorm, who also prompted me to look into multitouch in the first place) – suggested just reading the touchscreen event data from a file in the java layer as a quick way to skip over the hard work and demonstrate the possibility to people visually.

I will clean up and post all the necessary source code and instructions for someone to do this on their own phone so that more people can start playing with this later. For now, the brief rundown is that I modified the Synaptics touchscreen driver to have it create a character device at /dev/tsout that it dumps the touchscreen events to. I made /dev/tsout readable by the java layer, and then modified a fingerpaint example program that Google has posted to draw the circles. I have a thread in there that constantly polls that file, and when it sees data there it fires off an update event to the UI thread which scales the x and y position from the coordinate space of the touchscreen driver into the coordinate space of the android canvas and then draws a small circle there. I have it using a different color for the two fingers to make it easier to see.

The performance of this kind of polling is not that great. There are a few quirks to the multitouch aspect of the G1 – but the most important thing that I see is that even though it might not be a perfect multitouch screen capable of detecting millions of discrete touches – just being able to track 2 fingers should give me the only thing I really want… which is the ability to one day pinch to zoom in on the browser and get rid of those silly magnifying glasses.

Shameless plug Hey – if you want to hook a brother up, buy stuff from amazon and use this search box

None of the games currently look this good, and I can only imagine that once a game comes out that does use OpenGL ES, it wont be free. This app does provide a good preview of what kind of graphics we can expect on these phones – and they are every bit as impressive as the graphics that I’ve seen on other platforms.

Although I only got 24.5 FPS – one of the engineers inside of Google mentioned that: “this benchmark made us discover an issue with our GL stack… our graphics guy said we could almost double that number with the proper fixes”

So… Bring on the FPS, baby!