diff options
| author | 2022-12-15 05:00:46 +0000 | |
|---|---|---|
| committer | 2022-12-16 19:11:19 +0000 | |
| commit | 573b3791ce82052db970e59fcb59e4d814f36341 (patch) | |
| tree | 4899534b51349ead55e1bc092424f68f65ed2a37 /services/coverage/java | |
| parent | 018ce9f0b00247290773f334fa8d8894e7604fca (diff) | |
Remove isSyntheticPasswordBasedCredentialLocked()
As an additional cleanup, now that all users are guaranteed to have a
synthetic password (except for new users during early boot), remove the
isSyntheticPasswordBasedCredentialLocked() method and its callers.
Considering each case:
- In migrateFrpCredential(), the user is guaranteed to have an SP, since
they also have an LSKF. This was true even before "SPs on creation".
- In onThirdPartyAppsStarted(), any users in mEarlyCreatedUsers are
guaranteed to not have an SP yet, since their SP creation was delayed,
and the code that did on-demand SP creation has been removed (as it
should not have been reachable anyway).
- In getCredentialTypeInternal(), the LSKF-based protector ID is being
looked up anyway. It's more efficient to check that value for
NULL_PROTECTOR_ID, instead of doing a redundant lookup.
- In doVerifyCredential(), the check for an SP was redundant with later
checks. So, removing it doesn't change the behavior (other than the
log messages); VerifyCredentialResponse.ERROR is still returned.
Also, the SP should always exist here anyway.
- Similarly, in getHashFactor(), the check for an SP is redundant with
the check for NULL_PROTECTOR_ID in unlockLskfBasedProtector().
- In disableEscrowTokenOnNonManagedDevicesIfNeeded(), calling
destroyEscrowData() is harmless if there is no SP. But there should
always be an SP here anyway.
Test: atest com.android.server.locksettings
Bug: 232452368
Change-Id: I39ad1bdf84db745db85d4d8fcaaa1d989511d0e1
Diffstat (limited to 'services/coverage/java')
0 files changed, 0 insertions, 0 deletions