* 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.
