Android Lock Screen API Design
I want a better lock screen on my Android phone.
Moreover, I don't really want Google or HTC to design one. I really want a good API that allows others to design one. This is much the same design concept behind intents, widgets, etc; build the framework right, rather than building one particular implementation.
Which brings up the question: What would be a good lock screen framework for android?
Background
I made a previous Lock Screen Rundown. Since then I've also come across:
- WidgetLocker: A standard apk that replaces the lock screen. This allows widgets to be placed on the lock screen.
- AVLock: This patch requires root. It replaces the default home screen directly, and hence has none of the issues that others have been having with the current API.
It is also important when thinking about this to know what Google has said about the current API.
Desiderata
- Security
- Phone security
- It shouldn't be possible for an 'app widget' added to a lock screen to grant access to the phone when the phone is 'secure'.
- Not a trojan
- No Denial of Service (intentional or otherwise)
- Flexibility
- Able to replicate the default lock screen on any commercial hardware (e.g. Eclair, Sense, etc.)
- Able to replicate the 'lock screen replacement' apps currently on the market. (This is less important than the previous.)
- Able to adjust what (hardware buttons/shaking/???) wakes the device (but see security/DoS)
Use Cases
There appear to be two classes of use cases for the lock screen: standard and secure. By secure I'm referring to the 'pattern lock' that tries to keep prying eyes out of the phone.
- A simple lock screen that displays the time and has a keylock so you don't pocket-dial.
- A more complex lock screen that displays some simple information and also allows basic interaction (e.g. control the music playback). Has a keylock so you don't pocket-dial.
- A very detailed lock screen with lots of information and interaction, like FlyScreen.
- A simple secure lock screen designed to stop someone briefly alone with the phone from accessing it. The lock function doubles as a keylock to stop pocket-dialing.
- A secure lock screen that displays some information. e.g. transparently overlay the pattern lock on top of something like Pure Calendar.
- A secure lock screen that displays information and has some very basic interaction (e.g. a play/pause button)
- A complex secure lock screen that has multiple 'pages', some of which you can interact with. There is a mechanism to 'unlock' the
Design Ideas
I'm going to start with phone security ideas. The 'unlock' swipe pattern, either simple for a keylock, or complex for something more secure, is going to be an important part of the configurability of the lock screen. This means that it needs to be configurable too. BUT, it also has stronger security requirements. Hence my initial plan would be to separate these: have a plugable 'lock' widget and a separate pluggable information screen. The information app can be complex. The lock widget is significantly more tightly constrained.
Information screen
I'd imagine that the information screen is like a home screen. It can do whatever it likes, but all intents sent from this screen are ignored. There are two ways that this app can be dismissed:
- If the menu button is held down for 5 seconds then you're taken to a built-in back door that lets you in if you succeed at Google verification. This stops DOS attacks, intentional or otherwise.
- The lock swipe is implemented using (something like) the widget API. That widget has access to the API that dismisses the lock screen.
This ends up looking much like the current lock-screen apps, but cannot exit itself. If it does exit it could be restarted, or their could be a fallback.s
Lock Widget
As noted above, the lock widget is significantly constrained.
- When the lock widget is displayed, it is carefully drawn in its own window on top of the information screen. It can be transparent, showing the information screen behind, but no events in the lock screen pass through the information screen app. This stops password 'sniffing'.
- The lock widget's pixel values should never be visible to other user code.
- The lock widget's apk should never have any permissions (except reading from the sd-card?). (The idea here is that the plugin can get information from outside, but it cannot send any information anywhere. It can only get information from outside in ways that don't leak information, so net access is forbidden as information could be encoded in the URL accessed.)
- The lock plugins should never be able to broadcast or call any intents.
The currently designated lock plugin (and the menu-key override) are the only ways to dismiss the lock screen.
If the user specified a lock widget that just automatically dismissed the lock screen, then it is possible to pass control of unlocking back to the information screen.
Implementation Issues
- How do you make sure the information screen is sufficiently locked down? I think this could be similar to the current behaviour.
- How do you make sure that events for the lock widget cannot be captured by anyone else? This seems relevant. I don't know how that relates to widget embeddings. Is it possible to make a widget that keeps its events and pixels private?