Hackszine.com: Android Archives

Archive: Android

January 6, 2009

Get your T-Mobile G1 to show up correctly in iPhoto

G1 and iPhoto

Every time I plug my G1 phone into my Mac to download photos, iPhoto shows me only the videos that are on the phone, and I have to manually drag the photos from the Finder to iPhoto. It's only a minor annoyance,but fortunately the fix is very simple. If you navigate to your G1 in the Mac OS X Finder, you'll see that the DCIM folder (the usual home of photos on a digital camera) is titled "dcim" (lowercase). I made it uppercase, unmounted and remounted it, and iPhoto popped up with a list of the photos on the phone, ready to import.

December 29, 2008

Python on Android

If you have the Google Phone and prefer hacking Python over Java, this is just what you've been waiting for:

Here's an early Christmas present for all those Python fanatics (self included) out there! With a lot of help from my friends (thanks Manuel and Thomas!) I managed to install Python 2.4.5 on my G1. It's still rough around the edges, but I think it's a good start. Klaus Reimer has a nice overview of how to cross-compile Python. My instructions borrow a lot from his.

You'll need to do a bit of patching and cross compilation, but Damon's instructions are thorough enough to get you through it.

Python on Android

November 17, 2008

Android hack - a smarter garage door opener

Brad Fitzpatrick created a garage door application for his G1 Android-based Google Phone. This would be noteworthy enough, but the interesting thing about Brad's hack is that it opens the garage door automatically as he approaches his home.

I got it all working. I now have an Android Activity (GarageDoorActivity) which interacts with an Android Service I wrote (InRangeService), letting me start and stop the service's wifi scanning task. The service gets the system WifiManager, holds a WifiLock to keep the radio active, and then does a Wifi scan every couple seconds, looking for my house.

When my house is in range, it does the magic HTTP request to my garage door opener's webserver (HMAC-signed timestamped URL, for non-replayability/forgeability if sniffed) and my garage door opens. Complete with a bunch of fun Toast notifications (like Growl) and Android Notifications (both persistent ongoing notifications for background scanning, and one-time notifications for things like the garage door actually opening).

So when Brad comes home, he starts the application which scans the WiFi network and then opens the garage door as soon as his home network is in range. He even describes an automated version where the phone constantly monitors the network for common scenarios. For instance, your if your phone sees your work network disappear, followed an hour later by your home network appearing, it could safely assume you have come home from work, opening the door without any interaction.

This is compelling support for a fully hackable, open source device. With normal iPhone development, you don't this level of deep access to be able to monitor WiFi connectivity or run an application as a background process.

Brad's released the source code for this one. If this app gives you any ideas, his code might be a good place to start. Just make sure to send us a link to your Android hack when you get your G1 to turn lights on and off when you walk around the house.

Android Garage Door Opener
Download the Java Source

November 8, 2008

Quick workaround for the T-Mobile G1 root shell bug

Android Terminal Emulator

Update 1: It looks like the process respawns itself after you type exit, so Ed's suggestion of typing cat is the best one. So instead of typing exit, just type cat when your phone first boots up; this should render the rogue root shell harmless.

Update 2: I woke up this morning to find that an update was out for the G1 that fixes this. That happened pretty quickly (the last update trickled out to users pretty slowly).

I was freaked out about this awful bug in Android. Basically, there's a root shell running that executes every keystroke you type on the keyboard--as the root user, no less. The proof is simple, as Ed Burnette writes:

open the keyboard tray on your G1, ignore anything you see on the screen, and type these 8 keystrokes: <return>-r-e-b-o-o-t-<return>. Poof, your phone will reboot. This only works on a real phone, not in the emulator, and only with firmware version 1.0 TC4-RC29 and earlier.

Ed suggests typing cat to lock up the shell, ~~but here's a way you can completely shut down the rogue shell. Instead of typing reboot, type exit. That will shut the rogue shell down.~~ Ed's suggestion works by causing the shell to run the cat utility, which simply repeats whatever is fed into this. Because this rogue shell isn't tied to any terminal output, this repeated output won't go anywhere.

Each time you boot the phone, use the cat trick. If you're worried about typing random characters into the phone, press the red key, then the menu key. I've found that you can type these commands on the "Draw pattern to unlock" or "Press menu to unlock" screens. You'll need to do this until T-Mobile pushes out the update that fixes this (based on how the last update rolled out, it seems to take a week or more for them to distribute fixes to everyone).

If you want to see the offending process, run the command ps in the Terminal Emulator application (available for free in the Android Market), and you'll see a list of all running processes on the phone. At least on my phone, the rogue sh process is always started as process id 26. So if you run ps, you'll see something like this (output slightly abridged):



root     25    ... krfcommd

root     26    ... /system/bin/sh

system   27    ... /system/bin/servicemanager

Although I suggested in a previous version of this post that you could type exit instead of cat, that won't help, because Android's init.rc script respawns the rogue shell. For this reason, using the kill command to kill it won't work either. The best we can do for now is just wedge it up with cat.

If you had the time and inclination, you could edit the init.rc file that's the source of the problem. The only trouble there is that it's not on a normal filesystem, but in a ramdisk image that's unpacked each time you boot up, so you'd have to get your hands really dirty to make that fix.