The most common restore scenario is assumed to be moving from one device to another, like when the old one was lost or stolen. Most users probably don't continue to use the old device themselves still.
Since they just restored this backup on their phone, most data is already in this backup. Deduplication allows re-using that, so it doesn't need to be saved again.
Historically, metadata was uploaded to the backend after each app update and contained all essential data that is now in snapshots. We still support reading metadata for legacy backups and use the metadata classes as a common wrapper for snapshots. However, there is no need anymore to write out complete historic metadata and maintain duplicated unused information there. This got removed. THe information we do still save and write out is only for UI representation of backup state.
The time of last backup is now managed by SettingsManager.
This injects FileSelectionManager as a singleton, so we can use its selection to recreate a snapshot, even in a service.
Also includes some UI improvements.
Nextcloud has a bug that lets us write chunked transfers over quota:
https://github.com/nextcloud/server/issues/7993
However, when we upload small files, we can get the proper 507 response and thus detect out of space situations and warn the user about them.
and allow changing them dynamically. So far plugins were injected into the dependency graph and couldn't be changed at runtime, only their config could. Now we have the infrastructure in place to really allow for more than one plugin.
For ApkBackup, we need to be initialized. If the system starts with app backup off, we would not initialize which would lead to issues when backing up the APKs.
to avoid a 2nd restore set being used.
This also changes the initialization behavior to only create the restore set folder and upload the metadata only when we actually need to. This way, double inits are not creating new restore sets on the backup destination.
This is a preparation for doing APK backup ourselves in a worker and not hacked into the backup transport. The latter was prone to timeouts by the AOSP backup API. With a worker, we have a bit more control and can schedule backups ourselves.
If we request backup in several chunks, packages like 'pm@' or 'android' get backed up for each chunk, so due to incremental backups, we need to keep old data when comparing.
