If the foreground service doesn't have anything to do and terminates quickly, the system will kill us, even though the service had called startForeground(). To prevent this, we don't promise that our service will be a foreground service. We can still be a foreground service, but escape the punishment if we are too quick.
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.
* 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.
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.
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.
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.
