On Fri, Sep 3, 2010 at 8:42 AM, RickGillaspy <[email protected]> wrote:
> I don't understand why LOCK_PATTERN_ENABLED was added in then. > It is really more for the platform implementation than anything else. > 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? > It was used for the implementation. > and if applications can know about a lock pattern, why not the > existence of a pin or a password? > New stuff that we didn't need to expose so didn't. > 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. > The way this is supposed to work is that your device admin specifies the constraint it has on the device lock, and it can then check if the current lock meets that state (and ask the user at that point to change their lock if needed, or do whatever else it wants). -- 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
