Remove RunBackupReceiver
Currently, the logic for backupnow is split between UserBackupManagerService, RunBackupReceiver and BackupHandler. This makes it very confusing as the pre checks are split over three classes and there's no obvious reason why it is like that. On the other hand, requestBackup is split nicely into checks in UserBackupManagerService and starting the work from BackupHandler. This change removes RunBackupReceiver for backupNow and splits the logic only between UserBackupManager and BackupHandler - in the direction of making it consistent with requestBackup by moving the checks to UseBackupManagerService. (except the check for isBackupRunning which needs to be in the same synchronised block as setBackupRunning). Also, this CL moves the wakelock acquire from RunBackupReceiver (removed in this CL) to BackupHandler. Previously, RunBackupReceiver would acquire the wakelock and then send MSG_RUN_BACKUP. BackupHandler would then have to release that wakelock when it finds it cant run the backup because there's no transport. Now, the acquire is in BackupHandler after checking the transport. Therefore we dont need that release (when there's no transport) anymore A side benefit is we get rid of an extra hop to the broadcast receiver so potentially backups should be scheduled (albeit very slightly) faster. Test: atest -v RunBackupFrameworksServicesRoboTests Test: atest -v $(find frameworks/base/services/tests/servicestests/src/com/android/server/backup -name '\''*Test.java'\'') Test: atest -v CtsBackupTestCases Test: atest -v CtsBackupHostTestCases Bug: 147741497 Change-Id: I40051540c7e8531ef05076eab7ccc5b44b0c08d2
Loading
Please register or sign in to comment