tree 22db352630f1b0f9cf4e6ed30731dc6e427f0e7e
parent db72e3b421e38634376e1ce334cdea5d2c5e2fa6
author Rubin Xu <rubinxu@google.com> 1517993554 +0000
committer Rubin Xu <rubinxu@google.com> 1518081298 +0000

Simplify untrusted reset logic

Instead re-initializing the synthetic password, just call
setLockCredentialWithAuthTokenLocked similar to normal flow
since we have the cached auth token.

The existing synthetic password initializtaion flow actually
has a bug when an untrusted reset to clear password is invoked:
it wrongly assumes that it's in case 2 and creates a new SID for
the user, instead of clearing it. This leads to the CTS failure.

Test: On a FBE device, execute cts-tradefed run cts -m CtsDevicePolicyManagerTestCases
       -t com.android.cts.devicepolicy.MixedDeviceOwnerTestApi25 and verify device unlocks
       successfully after the reboot.
Bug: 72875989

Change-Id: I5939335a27b10528b772d193f1e1034fd79abb9b