DPM: Fix isActivePasswordSufficient for non-FBE devices
For non-FBE devices (devices will full disk encryption or no encryption at all) the password metrics are not kept in plaintext anymore, so it is not possible to evaluate the sufficiency of the password when new password quality requirements are set. Instead, the sufficiency value is stored in a checkpoint that gets loaded after boot and used before the user has entered any credentials. However this checkpoint value was not evaluated correctly (there was a circular dependency between setting it and reading it) and was not stored on the right DevicePolicyData object. Fix the checkpoint value to be the correct one and stored on the right object, by doing the following: * Removing the short-circuit introduced in ag/2866930. * Change the default checkpoint value to true, to prevent re-introducing b/63887564, and because a newly-created profile, before any password requirements are set, has a sufficient password. * Get rid of the circular dependency between setting and reading mPasswordValidAtLastCheckpoint, by extracting from isActivePasswordSufficientForUserLocked a function that does not look at the checkpoint value. * Store the checkpoint value in the DevicePolicyData object of the credential owner, as this is where isActivePasswordSufficient reads it. More details can be found in https://docs.google.com/document/d/15CRewlsy1lyonjAWg3VmhLC5jAyVKazUMKlcPnnId58/edit# Bug: 71697938,73347414 Test: cts-tradefed run commandAndExit cts-dev -s 127.0.0.1:56619 -a x86_64 -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceAdminHostSideTestApi23#testResetPassword_nycRestrictions -l DEBUG on a gce instance. Change-Id: Ide5b2e53cf100b087822844ca51b3bc69e7ddf82
Loading
Please register or sign in to comment