summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator.cpp
diff options
context:
space:
mode:
authorCharles He <qiurui@google.com>2017-04-21 13:45:34 +0100
committerCharles He <qiurui@google.com>2017-04-21 13:45:34 +0100
commitc93cdef2fa5403ac46767f1853f4e803824d4d20 (patch)
treeba091580b6b6d78a04563cbf305dbc55393f4098 /tools/aapt2/java/JavaClassGenerator.cpp
parenta017e573b5a900f6d7e0f1c6e4ed01fd569cc89f (diff)
Let unlocked profile verifyCredential under unified lock
When unified work challenge is enabled and the primary user is unlocked, LockSettingsService should unlock the managed profile subsequently by calling verifyCredential() in most cases. Previously, verifyCredential() is not called on managed profiles when any one of the two conditions are met: 1. when the profile is not yet running 2. when the profile is already unlocked These were introduced to make sure the managed profile stays locked when it is in QUIET_MODE (i.e. work mode off). However, condition 2 is problematic. Specifically, it also prevents auth tokens, etc., from being refreshed (side effects of verifyCredential()), even when the profile is not in QUIET_MODE. We remove condition 2 in this change to make sure verifyCredential() is still called on the managed profile when it is RUNNING_UNLOCKED. Condition 1 alone should be able to handle the QUIET_MODE case. Unit test is also updated in case regression occurs. Bug: 36851574 Test: runtest frameworks-services -c com.android.server.LockSettingsServiceTests Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests Test: CTS verifier > BYOD managed provisioning > Authentication-bound keys Test: (all of above are run on both sailfish and angler) Change-Id: Ice89c1eedacaf07e076252a2a571a1eb100ef791
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator.cpp')
0 files changed, 0 insertions, 0 deletions