I really have myself to blame. Android is the right smart phone platform for me: provided you have a rooted phone, you can get inside the device and tinker and there are community created ROMs which let you change the base system. It is effectively an embedded Linux platform with a java like application stack. I tend to follow the CyanogenMod crowd.
On my ADP1, I’ve got the developer friendly “fastboot”. Using this you can install what is called a “recovery image” – a secondary boot mode which lets you get in and do maintenance etc. Recently I found myself in a state where I had lost my recovery image. The forum has some good basic advice if this happens to you.
As I found myself needing to reinstall. The recommended recovery image is Amon_RA. I used the fastboot flash method, from my Ubuntu desktop using the fastboot binary. Once I had the binary, it really was as easy as booting into fastboot mode (hold camera button while phone is booting) and runnning the fastboot program.
fastboot flash recovery recovery_of_choice.img
Now what got me to this state of no recovery image, was most likely a finger fumble while I was trying to recover the phone from a bad state. (Did I mention I was to blame here?) Now I suspect there is some sort of latent bug in the Dalvik cache management that leads to this bad state, but I don’t yet have enough data to make a strong statement here.
What happens is at one point, apps stop opening properly for me. Specifically things like the web browser. The 1st time this happened, I ended up wiping the phone and starting again from scratch. While this is a recommended step if you’re going to play in the ROM scene, it is annoying to lose all of your state. To my dismay it happened again.
The symptom is a boot loop when you reboot. Using some of the tools from the Android SDK, you can watch things as they happen on boot. I use ddms for this. In the most recent failure, the loop looked like this in the log:
07-04 16:17:28.114: DEBUG/AndroidRuntime(249): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
07-04 16:17:28.114: DEBUG/AndroidRuntime(249): CheckJNI is OFF
07-04 16:17:28.284: DEBUG/AndroidRuntime(249): --- registering native functions ---
07-04 16:17:28.544: ERROR/AndroidRuntime(249): JavaVM unable to find main() in 'com.android.internal.os.ZygoteInit'
07-04 16:17:28.544: DEBUG/AndroidRuntime(249): Shutting down VM
07-04 16:17:28.544: WARN/dalvikvm(249): threadid=3: thread exiting with uncaught exception (group=0x4001e178)
07-04 16:17:28.574: DEBUG/dalvikvm(249): DestroyJavaVM waiting for non-daemon threads to exit
07-04 16:17:28.574: DEBUG/dalvikvm(249): DestroyJavaVM shutting VM down
07-04 16:17:28.574: DEBUG/dalvikvm(249): VM cleaning up
Not good. Something can’t be found that is fairly critical, so the Dalvik system is continually bailing out on its start-up, then trying again.
The fix was quite easy (if we ignore the step where during the investigation, I mess up my recovery image). The adb tool found in the Android SDK is much more powerful than I initially understood it to be. We can use it to stop the Android sytem.
> adb shell stop
This effectively stops the boot loop from spinning around and around. Now issuing:
> adb shell
Gets you into the device, and we can go and fix the filesystem. I located and cleared the Dalvik caches (deleted the contents of the directories).
cache/dalvik-cache
sd-ext/dalvik-cache
data/dalvik-cache
You may only need to clear the 3rd one, but that is the list I cleared out to get back into a working state. Much easier than a full wipe and reconfigure.
I like to buy movies, but I’m cheap. This means I usually pick up previously viewed movies, often in multiples to take advantage of the sale prices. This is one thing that digital media has changed the equation for, the used copy is exactly as good as the new copy with maybe the exception of the packaging.