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.
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
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.
additionally adding a test to ensure the storage provider is excluded.
Otherwise, when the storage provider (i.e. DAVx5 or Nextcloud) is installed,
it will be terminated, and the restoration process will be interrupted.
Change-Id: Ic1be201b673d718b416009ff61f5d975c89b6a62
Before, we were faking a backup and just returned true, but remembering that next time, we need to do a fresh non-incremental @pm@ backup.
Now, we backup to local cache, but don't upload it. On next run, when we can do backups again, we will upload the updated cache. This simplifies things and reduces the special logic required.
