This can happen when the app process gets killed while its BackupAgent is running. There are several qcom apps in the wild that have this issue. These are DoSing our backups and are non-free, so we are defending ourselves against them.
Before, we showed the number of apps we requested the backup for which in case of non-d2d may be much lower than the number of installed apps.
In the future we may decide to also include certain system apps in that count.
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.
Currently, after a manual run, we need to schedule the background backups again, because the scheduling gets lost. However, we need to be careful not to do that when the backup destination is on removable storage. Then we don't want to run.
Backup and restore is not possible when a backup is running. We used to check notifications for this, but now can use WorkManager's WorkInfo which should be more reliable.
Also, we used to prevent the "Backup now" action when app backup was disabled. But the user may want to do a storage backup. This is now possible.
When the user changes to USB storage, we need to cancel current schedulings, because the storage is not always available (maybe can use a trigger URI?). And if moving to a non-USB storage, we need to schedule backups again.
Unfortunately, there are two places in the code where we handle storage location changes. Ideally, those get unified at some point.
Previously, we backed up APKs of apps we could not back up (even if APK backup was disabled) so the user had a chance to get at least the apps back when restoring. Now, it is enough to record metadata about the app and the user will be able to manually install the app. The install apps step won't be skipped anymore.
and log worker ID as well as object, because we've seen two scheduled workers running at the same time, requesting a backup at the same time. This should not happen.
hopefully something rare, but it just happened to me while testing.
It seems it happens when there are many apps installed (>500) and the app list is open while a backup happens. Then, we keep reloading the list and hammer the package manager hard which it seems can't handle it. It does recover on its own though.
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.
