Fix unintended deletion of reused weaver slots during user removal
During user deletion, getNextAvailableWeaverSlot() might return a slot
that's currently taken by the to-be-removed user, because the user is
marked as partial so it's not returned from UserManager in the list of
users and SyntheticPasswordManager will not attempt to track which slot
that user has used. This slot might then be reused by a newly-created
user. Meanwhile SyntheticPasswordManager will also try to explicitly
delete slots for the deleted user during ACTION_USER_REMOVED, and if this
happens after the slot is reused by the new user, the weaver slot will
be corrupted, leading to failure to unlock the new user later.
Quick fix by double checking if slot is reused during user deletion.
Test: Add device lock; create work profile; reboot device; delete the
current profile and quickly re-create one. Verify the new profile
can still be unlocked after another reboot
Bug: 76134651
Change-Id: I89769b7cbcf64f2562717c98e3f15ab0fbb38bf0
1 file changed