summaryrefslogtreecommitdiff
path: root/docs/html/sdk/api_diff/16/changes
diff options
context:
space:
mode:
authorEran Messeri <eranm@google.com>2020-04-13 22:41:45 +0100
committerEran Messeri <eranm@google.com>2020-04-28 09:23:31 +0100
commit145d69a43d6333d3675746e59a121078f76ebdfb (patch)
tree20e41e06e191d22c854b450e08216b190fe1d43c /docs/html/sdk/api_diff/16/changes
parent2b40d3c462b59c18a3b62a813c26b6e483795491 (diff)
Fix work challenge lockscreen being dismissed
Fix the issue of the work challenge lockscreen being dismissed under the following circumstances: * The device has a managed (work) profile. * The work profile has a separate challenge than the primary one. * The phone is locked, and on the lock screen there's a notification associated with an activity in the work profile. In these circumstances, when the user double-taps the notification from the work profile, they have to enter the primary challenge first and then the work one. However, the issue is that the work challenge is shown for a fraction of a second, after the user enters the primary challenge, and then dismissed. The issue is caused by the lock screen still being shown when the ConfirmDeviceCredentialActivity is started. It is legal to start an activity when the device is locked, but it will be paused. The fix is to delay starting the ConfirmDeviceCredentialActivity until the lock screen is no longer shown. This is done by listening to the onKeyguardShowingChanged callback from KeyguardStateController.Callback: If, in startWorkChallengeIfNecessary, the keyguard is still showing, a callback listener is added to the KeyguardStateController. When the callback is invoked the ConfirmDeviceCredentialActivity is started. Bug: 141470517 Test: Manual, double-tap on a managed profile notification (see above) Change-Id: If85a5781cc2054165eb508cd9634980ce228addc
Diffstat (limited to 'docs/html/sdk/api_diff/16/changes')
0 files changed, 0 insertions, 0 deletions