Hi, The DeviceAdmin API is not going to contain this kind of functionality. That API is for apps to specify security limits they have; disabling the lock screen is not a security limit, but a removal. The admin API is carefully designed so that any constraints one admin specifies can not conflict with those of another; this is a situation we want to maintain, since otherwise there would need to be some way to decide which one "wins" (probably requiring the user to specify this), along with a way for an admin to find out when its requests are "losing" so it can deal with that.
Also typically an admin is there imposing requirements from a server, so if it can't impose those requirements it needs to stop pulling data from the service and erase any data it has from the service. Having that kind of thing happen at regularly times do to temporary conflicts with another admin would be fairly undesirable. The new device admin APIs also drove the changes to the lock screen interaction. For those APIs to work, we can't have a setting for someone else to disable the lock screen (and we had to change those settings anyway as the lock screen got more complicated in Froyo). For this reason the keyguard API to temporarily hide the keyguard no long does anything if there is any admin that is requiring a lock screen. We would certainly at some point like to support third party lock screens. However: (1) For the last two years this has been a low priority compared to many other things, and I can't say when that will change. Certainly not this year. (2) It will require some major refactoring of the current code, since the lock screen has very deep interactions with the window manager, power manager, telephony, etc. (3) A reasonable API will probably involve allowing an app to control the contents of the lock screen, but not when it is enabled, shown, etc (because those things require deep interactions with the rest of the system and so far have changed in every single update we have done). (4) If a device admin has imposed requirements on the lock screen, we would not be able to allow a third party lock screen because we have no way of trusting that it will impose the requirements that are being requested. On Thu, Jun 24, 2010 at 12:27 AM, LeveloKment <levelokm...@googlemail.com>wrote: > Hi Mark. > > Thanks for your answer. > > I share your point of view completely. > From my experience an always on (Pattern, Pin or Password) is > something many people do not like... so they deactivate it completely. > The idea of my App was to help people to find a good compromise > between security and usability. > > I already "reviewed" the DeviceAdmin class of Froyo as the SDK for 2.2 > was released. From my point of view it is the perfect location to > implement an interface that allows the temporary deactivation of the > locks (no matter if pattern, pin or password). > My fear was, that I was missing something and there is still a way to > satisfy my users even if they are using Froyo. > > An alternative to the DeviceAdmin would be collection of additional > settings in the related system settings section that give the users a > delay/timeout in Android natively (like some WinMobile devices are > doing it). That would make App's like my "PatternControl" needless. > > What is your advice to make the development team at least aware was > this "potential improvement"? > > Best Regards from Germany > Lars > > On 23 Jun., 12:58, Mark Murphy <mmur...@commonsware.com> wrote: > > On Wed, Jun 23, 2010 at 4:46 AM, LeveloKment <levelokm...@googlemail.com> > wrote: > > > No information? > > > > No, there is no way to deactivate the lock pattern that I am aware of. > > > > > No opinion? > > > > My opinion is that deactivating the lock pattern via a regular setting > > was a security hole. If the user wants a lock pattern, apps should not > > change that. If the user does not want a lock pattern, the user is > > perfectly capable of disabling it using the Settings application. The > > exception would be if an enterprise would want to mandate the lock > > screen be on and not disable-able, which runs counter to your apparent > > goals. > > > > My hope is that eventually stuff like this and custom lock screens > > will become part of the new device admin APIs. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.6 > > Available! > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@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. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
