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.
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.
If an app being restored was originally installed with F-Droid Basic,
try to install it using F-Droid Basic again.
Change-Id: Ib067389ba20d74596892e24efd561ab2918d62cb
Restore app data in smaller batches when performing a full restoration
from a backup set, to prevent a Binder exception that causes the
process to fail entirely.
Android may encounter this exception when trying to call the
transport.startRestore() method if too many packages are involved; in
testing, 300 is an example of too many. Instead of using
IRestoreSession.restoreAll(), use restorePackages() and provide the
package names in batches of 100.
This issue reveals itself when using SeedVault with the D2D patch and
with an OS, such as stock Pixel OS, that includes an abundance of
packages. (Prior to this patch, the call to restoreAll() meant that the
framework would request data restoration for all packages installed,
even if they were not in the metadata.)
In logs, this issue appears as follows:
```
I BackupManagerService: Full restore; asking about 300 apps
W BpBinder: Large outgoing transaction of 528540 bytes, interface descriptor <uncached descriptor>, code 14
E JavaBinder: !!! FAILED BINDER TRANSACTION !!! (parcel size = 528540)
E BackupManagerService: Unable to contact transport for restore: data parcel size 528540 bytes
```
Change-Id: Ibb5bb4572d9e873beccd6056da5fe3ae4dce71c2
Bip39ComparisionTest was run before and after upgrading org.bitcoinj:bitcoinj-core to latest version to ensure that kotlin-bip39 is still behaving the same.
A small tweak in WordListTest was needed because WorldList constructor was made internal.
* Pre-34, this was marked as @hide and @TestApi
* We were using it as a system app with hidden APIs allowed,
and having added the framework android.jar to gradle
* 91fa0b1298
made it public, so lint now complains. Silence that.
Change-Id: I5a1ec9847a25a0798726af3867d7660db1528a00
When `android.permission.MANAGE_DOCUMENTS` is not granted, Seedvault
prompts to select a storage location. Do not insist on resolving the
storage's actual root, as it will likely (or perhaps always) fail.
Use a fake storage root as is done for USB and app-based options.
Known issues:
* Selected location is assumed not to be USB and not to require
network access in its storage options.
Change-Id: I357b4c68673d71c087be41e9c94c2841c1d6658e
Disable new R8 mode and resource namespacing for now to avoid build failures.
These needs to be worked on before they can be enabled.
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
If you're using Android plugin for Gradle 3.0.0 or higher, your project automatically uses a default version of the build tools that the plugin specifies
Ref: https://developer.android.com/tools/releases/build-tools
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
