diff options
| author | Rubin Xu <rubinxu@google.com> | 2018-02-07 08:52:34 +0000 |
|---|---|---|
| committer | Rubin Xu <rubinxu@google.com> | 2018-02-08 09:14:58 +0000 |
| commit | 9a6d39a5d79687bbdc80c554bc524d7dfc2c5f20 (patch) | |
| tree | 22db352630f1b0f9cf4e6ed30731dc6e427f0e7e /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | db72e3b421e38634376e1ce334cdea5d2c5e2fa6 (diff) | |
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
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions