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.
This will only hide installed apps from naive attackers as the APKs are still not encrypted and even then other attacks would be possible.
However, it allows us to simplify our storage plugin API.
This is the same behavior as Google backup when it has no internet connection and after extensive research the only option we can keep the system from considering the backup state to be compromised.
K/V backups are run at least every day, no matter what backup interval we set in settings and when they run, we don't get asked before, if now is a good time for backups. So we need to fake an OK for @pm@ backup and can error out afterwards without compromising state.
K/V backups are normally only attempted when charging and having an (un-metered) internet connection. However, if the system could not do a backup for more than a day, it ignores these requirements and still attempts a backup run. If a backup storage is used that is only accessible on the internet, but there is no internet connection, the backup attempt will fail. Therefore, we check if our storage requires the internet and if so, we treat it similar to a removable storage, by rejecting backup attempts and suppressing error notifications.
There is a possibility that incompatible APK splits make a an app crash when starting after re-installing it.
With that config option each OEM can decide with they want to take this risk or not.
that tries to figure out compatibility only based on the name of the split.
This is not an exact science and there might be errors, but we hope to correctly identify most cases that matter in practice.
We are re-installing system apps if they are present on the restore device as a system app and have a newer version code.
Before, when one of those conditions is not true, we were showing a failure and gave the user the option to re-install the app from an app store.
Now, we don't offer the manual re-install option anymore and only show a success when a newer or same version of the system app is already installed.
When one or more apps fail to install, the user is shown a dialog explaining that we need the apps installed in order for restore to work.
After the dialog is dismissed, the list of apps is resorted so failed apps are at the top. They are made clickable and the user is brought to an app store to re-install them.
Apps that have FLAG_STOPPED will not get backed up, just like apps
without flag ALLOW_BACKUP will not get backed up.
In the UI both cases are shown the same way: app does not allow backup
This can be confusing for the user as it is not true for stopped apps.
Therefore, this commit introduces a new stopped state for apps,
so we can differentiate between both cases.
This commit makes creating new RestoreSets explicit.
Initializing a backup transport now actually cleans its data as the AOSP
documentation demands. This should be fine as we usually do a fresh
backup after a new initialization.
Contrary to before, an initialization does not create new RestoreSets
anymore, but works within the existing set. For now, only manually
choosing a new storage location creates a new RestoreSet.
Fine-grained progress reporting causes apps to show up twice which is
confusing. Also @pm@ metadata and opt-out APKs are too much detail for
normal users. So we decided to only show a percentage in the progress
notification.
When the backup finished, the app now shows "x of n apps backed up"
which is more positive when the previous negative message of how many
apps were not backed up.
Some further minor tweets were done to app counting to report proper
totals.
This adds @pm@ record backup and APK backup of opt-out apps to the
progress reporting since these two operations are slow when using a
cloud storage SAF backend.
Loading cursors can happen with cloud-based documents providers
such as Nextcloud.
When they return a cursor that is still loading,
we might continue with stale information.
So now we wait for a loading cursor to be fully loaded
before continuing.
This should also affect apps that have other errors during the backup
process, but it does not affect apps that opt-out of backup completely.
First part of #65
Apps that have nothing to back up start a backup but then get a call to cancelFullBackup()
and never even call finishBackup().
Do not write metadata for such apps, the call got moved to finishBackup().
These might return outdated or now content when queried,
then check their cloud storage and report back with up-to-date content.
We now detect this (when looking for backups on newly setup storage)
and wait until the content has been loaded before acting on the
response.
This is affecting and was tested with NextCloud.
