I wonder how secure the screen lock pattern option really is. I notice that the OS requires that the user draw at least four dots in their pattern. In theory, then, you have sum((9!/5!)+(9!/4!)+...)=9!(sum(1/n!)) options, where the integer n ranges from 0 to 5 (representing the 6 dot count options), or 985,824 total options. That's almost 20 bits strong, similar to a 6-digit base-10 pin.

BUT: That's if you use it like Swype for a 9-digit keypad, choosing a truly random 4- to 9-digit pin with no repeating digits. I'm not sure that's really possible: can you move between opposite corner dots without hitting the center dot? I speculate that in practice this input mechanism encourages a much smaller pool of options. For instance, in my anecdotal experience most users will only move to adjacent dots and won't cross their lines (presumably due to their cultural heritage of Tron and Ghostbusters). That turns this into a graph problem, and you would probably have to write a simulator to get the real numbers.

... Here's that simulation, in C++: http://pastebin.com/xKd7UMr3

Note that the adjacency constraint implies the no-crossing-lines constraint. Total possible paths given the constraints: 10096. That is a nontrivial reduction in bit strength, from 20 bits to less than 14, or from 7 to 5 base-10 digits. As a complimentary check, if you eliminate the adjacency constraint in the simulator you will see the expected 985,824 number.

Experimentation on my Droid X running the 2.2 OS indicates that you not only must wait 30 seconds after every 5 invalid patterns, but are locked out completely after 20 (at which point you have to login with your Google account to regain access). The OS remembers the number of invalid attempts across reboots, even if you abruptly cycle the power by pulling the battery out of your poor little Droid X.

Suppose an Android phone firmware was not quite properly implemented, and the invalid attempt count was only flushed to nonvolatile memory every, say, five attempts. I might then build a brute force pattern cracking machine, something servo-driven with a stylus to contact the screen (à la Clarke's "Rama II"). If my cracking device takes 3 seconds to try a pattern, and assuming a 40-second boot time, I would need 52 seconds to make 4 guesses, or 13s/guess. For the ideal case of 985,824 equally likely options, I would have to run that machine continuously for over 21 weeks to try every pattern. Given the adjacency constraint, however, I would need less than 37 hours -- a day and a half! -- to try all 10096 possible patterns, and would expect an average search time of about 18 hours.

Would the average user change their passwords if they accidentally left their smartphone in the office for the weekend (60 hours)? But this doesn't even need to be a single block of time. Does your significant other have access to your smartphone during weeknights (8hrs * 5 days = 40 hrs)?

Though if you have the kind of significant other who discovers your phone has a minor firmware flaw, builds a servo-driven cracking device to exploit it, and proceeds to steal your phone every night while you sleep, your life was going to be difficult anyway.

[EDIT: "No crossing lines" is a vague description. What I mean is that I don't see many users go back across a previously-visited dot to reach an unvisited dot. Since a dot on the other side of a previously-visited dot would have to be at least two dots away, the line-crossing constraint is covered by the adjacency constraint. As far as I can tell, the line-crossing constraint is actually somewhat enforced by the Android OS: you are not allowed to cross over unvisited dots without the OS forcibly "visiting" the intermediate dot on your behalf, although you are allowed to cross over visited dots.]