Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d44bb770 authored by Eric Biggers's avatar Eric Biggers
Browse files

KeyguardManager: clarify behavior for profile with separate challenge 

In my improvement to the KeyguardManager documentation a couple months
ago (https://r.android.com/2747678), I didn't mention anything for
profiles with a separate challenge because it wasn't yet clear what
isDeviceLocked() and isDeviceSecure() return for them and whether they
work as expected in this case.  However they do appear to work as
expected in this case, so update the documentation to cover this case.

Bug: 128589540
Test: N/A
Flag: DOCS_ONLY
Change-Id: I3762a47279f43e2a37c89c49c52380cf08d2f802
parent b932bbb9

core/java/android/app/KeyguardManager.java

+18 −9
Original line number Diff line number Diff line
@@ -679,10 +679,11 @@ public class KeyguardManager { 
     * <p>

     * Specifically, this returns {@code true} if at least one of the following is true:

     * <ul>

     *   <li>The {@link Context}'s user has a secure lock screen. A full user has a secure lock

     *   screen if its lock screen is set to PIN, pattern, or password, as opposed to swipe or none.

     *   A profile that uses a unified challenge is considered to have a secure lock screen if and

     *   only if its parent user has a secure lock screen.</li>

     *   <li>The {@link Context}'s user has a secure lock screen. A full user or a profile that uses

     *   a separate challenge has a secure lock screen if its lock screen is set to PIN, pattern, or

     *   password, as opposed to swipe or none. A profile that uses a unified challenge is

     *   considered to have a secure lock screen if and only if its parent user has a secure lock

     *   screen.</li>

     *   <li>At least one SIM card is currently locked and requires a PIN.</li>

     * </ul>

     * <p>
@@ -729,8 +730,15 @@ public class KeyguardManager { 
     * <p>

     * For a user that is not the current user but can be switched to (usually this means "another

     * full user"), and that has a PIN, pattern, or password, the device is always considered

     * locked. For a profile with a unified challenge, the device is considered locked if and only

     * if the device is locked for the parent user.

     * locked.

     * <p>

     * For a profile with a unified challenge, the device locked state is the same as that of the

     * parent user.

     * <p>

     * For a profile with a separate challenge, the device becomes unlocked when the profile's PIN,

     * pattern, password, or biometric is verified. It becomes locked when the parent user becomes

     * locked, the screen turns off, the device reboots, the device policy controller locks the

     * profile, or the timeout set by the device policy controller expires.

     *

     * @return {@code true} if the device is currently locked for the user

     * @see #isKeyguardLocked()
@@ -757,9 +765,10 @@ public class KeyguardManager { 
     * Returns whether the user has a secure lock screen.

     * <p>

     * This returns {@code true} if the {@link Context}'s user has a secure lock screen. A full user

     * has a secure lock screen if its lock screen is set to PIN, pattern, or password, as opposed

     * to swipe or none. A profile that uses a unified challenge is considered to have a secure lock

     * screen if and only if its parent user has a secure lock screen.

     * or a profile that uses a separate challenge has a secure lock screen if its lock screen is

     * set to PIN, pattern, or password, as opposed to swipe or none. A profile that uses a unified

     * challenge is considered to have a secure lock screen if and only if its parent user has a

     * secure lock screen.

     * <p>

     * This method does not consider whether the lock screen is currently showing or not.

     * <p>