-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turning off "Backup my apps" prevents existing backup from being restored #476
Comments
Ignore AOSP's attempt to wipe backup data when backups are disabled. Remaining quirks: * When backups are re-enabled and another backup is started, the system will call initializeDevice, and Seedvault will generate a new backup salt and start the backup from scratch. This was already the case, and this patch does not change that. Issue: seedvault-app#476 Change-Id: I6ab41a885fcf7c4143814ebe849b8263a4f6e595
Ignore AOSP's attempt to wipe backup data when backups are disabled. Remaining quirks: * When backups are re-enabled and another backup is started, the system will call initializeDevice, and Seedvault will generate a new backup salt and start the backup from scratch. This was already the case, and this patch does not change that. Issue: seedvault-app#476 Change-Id: I6ab41a885fcf7c4143814ebe849b8263a4f6e595
One alternative to ignoring the BackupManager as done in PR #477 could be to track backup enablement separately within Seedvault, keeping it enabled as far as the system is concerned, and postpone backups that are requested by the system indefinitely when backups are turned off, as has been contemplated for a time at which Seedvault implements its own scheduling (if this happens). |
Ignore AOSP's attempt to wipe backup data when backups are disabled. Remaining quirks: * When backups are re-enabled and another backup is started, the system will call initializeDevice, and Seedvault will generate a new backup salt and start the backup from scratch. This was already the case, and this patch does not change that. Issue: seedvault-app#476 Change-Id: I6ab41a885fcf7c4143814ebe849b8263a4f6e595
Why does the time field for the existing backup set becomes zero? And why does that change get uploaded to the server before starting a new backup set? (Haven't had time to review the open PR yet, but want to understand the above first anyway.) |
Turning off backup, to AOSP, "also constitutes an opt-out, so we wipe any data for this device from the backend" (UserBackupManagerService.java). To do this, AOSP calls initializeDevice on the transport, which eventually makes it to Seedvault's MetadataManager.onDeviceInitialization, whose doc states, "Existing [BackupMetadata] will be cleared". |
We've seen it do this in a lot of situations, so killing the existing backup is probably not a good idea. We could start a new restore set, but not kill the old one, I'd say. |
Let the user know that turning off backups will cause their existing backups to become unusable, if they are accessible. This behavior is already very confusing and we may want to tweak it. Whatever wording we ultimately use for this, it should reflect the actual behavior at the time. In AOSP, turning off a backup transport signifies a user's intent to opt out of the backup system and delete all existing backups. We do not currently implement the same behavior, but we do receive the call to initializeDevice, which results in clearing the backup metadata, if available; it is not available if the backup location is a USB device that is not plugged in, for example. Cleared backup metadata means a backup time of 0, and a backup set that cannot be restored. Issue: seedvault-app#476 Change-Id: I22a1cebd272ac43cab6c68b99ace5919d6a7a9f5
Let the user know that turning off backups will cause their existing backups to become unusable, if they are accessible. This behavior is already very confusing and we may want to tweak it. Whatever wording we ultimately use for this, it should reflect the actual behavior at the time. In AOSP, turning off a backup transport signifies a user's intent to opt out of the backup system and delete all existing backups. We do not currently implement the same behavior, but we do receive the call to initializeDevice, which results in clearing the backup metadata, if available; it is not available if the backup location is a USB device that is not plugged in, for example. Cleared backup metadata means a backup time of 0, and a backup set that cannot be restored. Issue: seedvault-app#476 Change-Id: I22a1cebd272ac43cab6c68b99ace5919d6a7a9f5
Let the user know that turning off backups will cause their existing backups to become unusable, if they are accessible. This behavior is already very confusing and we may want to tweak it. Whatever wording we ultimately use for this, it should reflect the actual behavior at the time. In AOSP, turning off a backup transport signifies a user's intent to opt out of the backup system and delete all existing backups. We do not currently implement the same behavior, but we do receive the call to initializeDevice, which results in clearing the backup metadata, if available; it is not available if the backup location is a USB device that is not plugged in, for example. Cleared backup metadata means a backup time of 0, and a backup set that cannot be restored. Issue: seedvault-app#476 Change-Id: I22a1cebd272ac43cab6c68b99ace5919d6a7a9f5
Let the user know that turning off backups will cause their existing backups to become unusable, if they are accessible. This behavior is already very confusing and we may want to tweak it. Whatever wording we ultimately use for this, it should reflect the actual behavior at the time. In AOSP, turning off a backup transport signifies a user's intent to opt out of the backup system and delete all existing backups. We do not currently implement the same behavior, but we do receive the call to initializeDevice, which results in clearing the backup metadata, if available; it is not available if the backup location is a USB device that is not plugged in, for example. Cleared backup metadata means a backup time of 0, and a backup set that cannot be restored. Issue: seedvault-app#476 Change-Id: I22a1cebd272ac43cab6c68b99ace5919d6a7a9f5
Let the user know that turning off backups will cause their existing backups to become unusable, if they are accessible. This behavior is already very confusing and we may want to tweak it. Whatever wording we ultimately use for this, it should reflect the actual behavior at the time. In AOSP, turning off a backup transport signifies a user's intent to opt out of the backup system and delete all existing backups. We do not currently implement the same behavior, but we do receive the call to initializeDevice, which results in clearing the backup metadata, if available; it is not available if the backup location is a USB device that is not plugged in, for example. Cleared backup metadata means a backup time of 0, and a backup set that cannot be restored. Issue: seedvault-app#476 Change-Id: I22a1cebd272ac43cab6c68b99ace5919d6a7a9f5
With #750 we don't touch old restore sets and init is a no-op. |
When turning off "Backup my apps", the existing backup set becomes unusable for restore. Attempting to restore the set follows through the usual process of entering the recovery key, but then leads to this message: "No suitable backups found at given location" and the following in logcat:
I can replicate this both with USB backup/restore and Internal Storage backup/restore. It has happened when restoring to the main user and restoring to a work profile. It is reproducible whenever "Backup my apps" had been turned off.
Debugging
After turning off "Backup my apps", Seedvault disables the backup service. For some reason, this (or something else related to turning this off) leads to BackupManagerService re-initializing the transport, which reinitializes the device, causing
BackupMetadata
to be cleared. Thetime
field for the existing backup set becomes zero, and the above error occurs. (See logcat snippet further down.)The documentation for IBackupManager.setBackupEnabled() doesn't suggest to me that this should happen; in fact, to me, it suggests the opposite, by discussing how data-changed notifications will continue. Nevertheless, it does happen.This appears to be intended behavior on the AOSP side, when disabling backup. See UserBackupManagerService.updateStateOnBackupEnabled().
To work around this, perhaps Seedvault could disregard initialization calls from AOSP when backup is disabled, or - more simply - take some measures to ensure that the backup set is not modified when "Backup my apps" is turned off, unless fully intended.
logcat when turning off "Backup my apps"
The text was updated successfully, but these errors were encountered: