As most output streams come from the system, we can't re-send them. So when okhttp wants to retry it tries to write to closed streams which will fail. We declare our outputstream writing as one-shot for this reason.
Apps are now restored alphabetically to be consistent with the other lists. Some irrelevant apps are hidden. Under the hood, we now use an AsyncListDiffer like in the other lists.
AppDataRestoreManager
which was in RestoreViewModel before.
Now all three steps of app restore have their own dedicated manager class making the ViewModel more readable.
during restore process. These can usually not be manually installed anyway and just clutter the list making it harder for the user to find their important apps and potential failures there.
While we still don't guarantee that an attacker with access to the storage can't find out which apps we use (APKs are still unencrypted after all), we go into this direction.
Also, this should make it impossible for an attacker that can modify files to replace or otherwise mess with the icons.
This fixes broken AGP Upgrade Assistant in Android Studio as well as detects
the version catalog files in Android view.
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
* We should not bypass the OS-wide APK install restriction.
* Simply treat that as just not having the APK in the first place,
since we do support that as an option.
* This still lets users install apps via the store it was downloaded
from, if said store is installed and allowed to install apps.
* Introduce InstallRestriction to make testing easier.
Co-Authored-By: Torsten Grote <t@grobox.de>
Change-Id: Ic0a56961c9078d4dd542db5d9fc75034abb27bea
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.
this is important, so we don't allow more than one backup running at the same time and not swapping out the storage while one is running.
Previously, we had some bare bones tracking, but nothing precise.
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.
This is especially useful for WebDAV storage where the user can supply whatever URL and before proceeding, we need to know whether that URL and the provided credentials are actually working.
We use the same root folder for app and files backup. App backup usually creates the root folder, but if only storage backup is used, it will be missing and needs to be created.
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
