Breaking out LockScreen functionality from the platform, cont.

[martin]

Hi!

I would like to re-start the discussion at
http://groups.google.com/group/android-contrib/browse_thread/thread/d55135081e668ab2/78fc0e5f872df85e?lnk=gst&q=lockscreen#78fc0e5f872df85e
(which have now been inactive for awhile which forces me to start a
new Google groups-discussion).

We have just started to look at the topic of breaking out the
LockScreen from the platform again, and would very much like to
continue the previous discussion. Our understanding from the previous
conversation is that there is some Google interest for the solution
that Tobias has suggested in the thread above, although there are lots
of issues that remains to be solved.


I would also like to discuss a tweak of the previous suggestion, that
could potentially save us from a lot of the security related concerns.
What if we would replace the lockScreen only, and let the native
unlockScreen remain as is? This would keep the phone safe, and we will
avoid all unlock related problems pointed out previously (device-admin
coordination, safe mode, non-supported unlock types in the
applications etc). The KeyguardViewMediator would detect when the
external lockScreen window is removed, and then poke the
KeyguardViewManager to show the unlock Screen (possible through the
existing verifyUnlock call).

The obvious drawback of course is that we limit the possibility to do
your own fancy unlock Screens. Should be ok though; it is in the lock
Screens you want to be fancy; not the unlock Screens.

We have not prototyped this yet, but what is your general opinion?



For the external lockscreen, we have a working prototype (which does
not include the unlock functionality). There are some issues to be
solved, but all-in-all it works quite well.

Best Regards,

Martin Andersson

Sony Ericsson

[Dianne Hackborn]

Hi, we are not going to be able to accept such contributions at this point.  The lock screen literally has been changing significantly every release.  This means that it is both hard to sync up work going on in it with an external contribution, and we are not at the point where we are comfortably committing to a public API for it.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.