which manages interactions with snapshots, such as loading, saving and removing them.
It also keeps a reference to the latestSnapshot that holds important re-usable data.
This class is responsible for caching blobs during a backup run,
so we can know that a blob for the given chunk ID already exists
and does not need to be uploaded again.
It builds up its cache from snapshots available on the backend
and from the persistent cache that includes blobs that could not be added to a snapshot,
because the backup was aborted.
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.
