Allow migration to SP to be rolled back by filesystem checkpoint
On upgrade from Android 13 or earlier, LockSettingsService is creating a synthetic password (SP) for all users that didn't have one before, and re-encrypting the user's CE key with the SP. Currently this happens at PHASE_BOOT_COMPLETED, since Weaver is not yet guaranteed to be available at the previous phase, PHASE_THIRD_PARTY_APPS_CAN_START. An issue with using PHASE_BOOT_COMPLETED is that during an upgrade, PHASE_BOOT_COMPLETED happens after the userdata filesystem checkpoint has already been committed. Therefore, if a problem occurs with the migration to SP, the changes won't be rolled back and the device will be left in a broken state, recoverable only via a factory reset. Important migrations like this should happen before the checkpoint is committed. Therefore, replace the use of PHASE_BOOT_COMPLETED with a direct call into LockSettingsService in an appropriate place, similar to the existing LockSettingsService.systemReady() call. I also considered creating a PHASE_THIRD_PARTY_APPS_STARTED boot phase. However, any new boot phase would become part of the services API (services/api/current.txt), which is more than I'd like to do here. Test: Made an intentionally broken build with LockSettingsService.onThirdPartyAppsStarted() changed to throw a RuntimeException at the end, crashing system_server. Tested an OTA from tm-qpr2-release to that build, on a device that didn't have a lockscreen credential set on user 0 (so that user 0 was migrated to SP-based credentials just before the crash). The OTA failed as expected and successfully rolled back to the original build, with user 0's data still accessible (this was not possible before this change). Bug: 232452368 Change-Id: I77d30f9be57de7b7c4818680732331549ecb73c8
Loading
Please register or sign in to comment