The system triggers backup jobs periodically or when a package is
announcing that its data has changed. So far we were not showing
notifications for those. This commit shows a notification with an
indeterminate progress bar as we don't have any information about how
many packages will get backed up.
It turned out that call log backup is already in AOSP, but it is
disabled by an undocumented flag. This commit sets this flag (for new
and existing installs) to enable call log backup.
This commit makes creating new RestoreSets explicit.
Initializing a backup transport now actually cleans its data as the AOSP
documentation demands. This should be fine as we usually do a fresh
backup after a new initialization.
Contrary to before, an initialization does not create new RestoreSets
anymore, but works within the existing set. For now, only manually
choosing a new storage location creates a new RestoreSet.
Fine-grained progress reporting causes apps to show up twice which is
confusing. Also @pm@ metadata and opt-out APKs are too much detail for
normal users. So we decided to only show a percentage in the progress
notification.
When the backup finished, the app now shows "x of n apps backed up"
which is more positive when the previous negative message of how many
apps were not backed up.
Some further minor tweets were done to app counting to report proper
totals.
This adds @pm@ record backup and APK backup of opt-out apps to the
progress reporting since these two operations are slow when using a
cloud storage SAF backend.
Loading cursors can happen with cloud-based documents providers
such as Nextcloud.
When they return a cursor that is still loading,
we might continue with stale information.
So now we wait for a loading cursor to be fully loaded
before continuing.
This restores only the @pm@ keys that are really needed
and thus speeds up installation with auto restore considerably
when using cloud storage such as NextCloud for example.
@stevesoltys this removes your old way of retreiving installed packages
via getInstalledPackages(0, UserHandle.USER_SYSTEM) as I couldn't find a
difference to the official way.
Also IGNORED_PACKAGES isn't needed anymore since
filterAppsEligibleForBackupForUser() already filters those out.
This should also affect apps that have other errors during the backup
process, but it does not affect apps that opt-out of backup completely.
First part of #65
