I don't understand why LOCK_PATTERN_ENABLED was added in then. If we don't want applications knowing or depending on if there is a screen lock enabled, why let applications know all that information about a lock pattern?
and if applications can know about a lock pattern, why not the existence of a pin or a password? I'm trying to report the state of the device to a server that is specifying security parameters. Other devices can report if a pin is set, and if it is compliant with the current policy. I cannot. I can only know if the current password ( if it exists) is compliant. I can't determine the difference between where a lock pattern/pin/ password is set, but is insufficient quality and the case where a lock pattern/pin/password is not set at all. What is the use case for an application that needs to know if a lock pattern is enabled, but doesn't care about any of the other screen lock possibilities? On Aug 8, 10:08 pm, Dianne Hackborn <[email protected]> wrote: > The DevicePolicyManager returns information about the policies that admins > have requested. The user just setting it to something is not a policy being > enforced by an admin. Admins use this to determine whether the currently > set password meets the requirements they have > requested:http://developer.android.com/reference/android/app/admin/DevicePolicy...() > > <http://developer.android.com/reference/android/app/admin/DevicePolicy...()>I > don't know off-hand of a way to know about whether other types of passwords > are set. We are trying to obscure that information for security reasons, > and generally it is not stuff we want applications having dependencies on > since it is easy for that to lead into assumptions about current behavior > that may not hold in the future. > > > > On Sat, Aug 7, 2010 at 9:00 PM, GodsMoon <[email protected]> wrote: > > I'm also interested in this. > > I can't find anything like LOCK_PASSWORD_ENABLED or LOCK_PIN_ENABLED > > in the docs. I assume > > Anybody know if it will be in Gingerbread or if its somewhere else > > that I'm missing? > > > I've been looking at DevicePolicyManager > > >http://developer.android.com/reference/android/app/admin/DevicePolicy...) > > It looks like mDPM.getPasswordQuality(null) should work but it > > doesn't. > > As far as I can tell getPasswordQuality(admin | null) always returns > > zero even with the Sample Device Admin enabled. > > Possible bug? > > > Thanks, > > David Shellabarger > >http://www.nightshadelabs.com > > twitter.com/godsmoon > > > On Jul 22, 3:23 pm, Joseph Earl <[email protected]> wrote: > > > It is working correctly.LOCK_PATTERN_ENABLEDtells you only about if > > > the lock pattern is enabled. It has nothing to do with the password as > > > far as I am aware. > > > I'm afraid I do not know how to tell if the password lock is enabled > > > or not, a quick scan of the docs didn't reveal anything to me. > > > > On Jul 21, 3:29 pm, Nea <[email protected]> wrote: > > > > > According to the documentation System.Secure.LOCK_PATTERN_ENABLED > > > > tells you whether the autolock is enabled or not. If you set a lock > > > > pattern it will return true and if you don't set any screen lock it > > > > will return false, which is all in order. > > > > > However on the Android virtual device emulator you could set a screen > > > > lock with a pin code or password instead of a lock pattern. But if you > > > > set a pin or passwordLOCK_PATTERN_ENABLEDwill return false instead > > > > of true. Isn't this a bug? Or is there another way to find out if a > > > > screen lock is set or not (independent of it's a lock pattern, pin or > > > > password)? > > > > > This seemingly wrong behaviour has also been discovered on a Motorola > > > > Milestone device with Android 2.1 installed. It let's the user set a > > > > lock pattern or password as a screen lock, however if a password is > > > > setLOCK_PATTERN_ENABLEDwill return false. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
