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.
and cancel observer notification when backup is finished. This is because when the success channel is disabled by the user, the observer notification could stick around and would never get removed.
* Bump version
* 33030020 -> 13-3.2
* 33030021 -> This, d2d test #478
* 33030022 -> Next, to go back to normal build after testing #489
* Set the testing property to true so that the system
sends us the right app list
14597: Optionally have System-scheduled backups act as migrations | https://review.calyxos.org/c/CalyxOS/platform_frameworks_base/+/14597
Change-Id: I278091b6659db095716e01b6c3894ce345219283
Allow backup of apps that would otherwise only support device-to-device
migration. This is an initial-support patch to help determine the
viability of this approach.
Known issues / TODO:
* System-scheduled backups will not handle D2D-only apps, unless
accompanied by a framework change forcing OperationType.MIGRATION.
Backups triggered by the connection of a USB device or by Seedvault's
StorageBackupService (files) scheduling are not affected, so they
*will* back up D2D-only apps as expected; otherwise, the user may
need to perform a backup manually via Backup Now.
* Apps with `allowBackup="false"` will appear in Backup Status under
"Installed Apps" rather than "Apps that do not allow data backup",
and their status will always be blank until they have been backed
up. If they are not eligible for migration, it will never change.
Other notes:
* The unit test for excluding the Storage Plugin provider from backups
was discussed, deemed unnecessary, and removed.
Co-authored-by: Oliver Scott <olivercscott@gmail.com>
Change-Id: I5a23d68be66f7d8ed755f2bccb9570ab7be49356
We emit the install result of APKs at least two times. When there is no APKs to install, because APK backup was disabled, we would start the restore of app data two times.
This fix waits until the emitted install result is considered finished, so we only start data restore once.
