On Android 11 this worked fine, but on Android 12 onStart() happens before activity results get delivered. We finish the activity when receiving a cancelled result. However, when onStart() gets called before we know the result, we relaunch an activity required for provisioning again instead of finishing.
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.
We ask the user to generate a new key, because actively asking for the old one is training bad security habits, but technically verifying the old key will also work.
* We don't show Restore in menu by default since it's
not the best idea to restore a running system
* However, at the same time, it's good to have a way to do
that for those who'd like to restore anyway, and the only
current way is adb, which is not ideal
* Dialing "*#*#RESTORE#*#*" will launch the restore activity
Change-Id: I258fead82f7e916a4de0b314e1840d7aa4b3746c
This is may be inconvenient for some people, but it is way more secure as screenshots can be accessed by malicious apps that look our for BIP39 codes. Better to store the code on paper.
This will help to prevent data extraction via seedvault when somebody gets hold of an unlocked phone. However, it will not help against someone able to force you to provide fingerprints or other device secrets.
Attempting to install Nextcloud in SetupWizard on a device
that has no app store installed results in a crash.
Disable the option and use an appropriate summary.
Change-Id: Ie3dff8d85ed68b27858fa37b3efb97eb345fa372
* We better not overuse metered networks as such connections
* are usually sensitive to heavy data usage due to monetary costs and/or data limitations.
* delete all storage backups for current user
* clears the storage backup cache
* start a new app data restore set and initializes it
The reason is that old backups won't be readable anymore with the new key. We also can't delete other backups safely as we did before, because we can't be sure that they don't belong to a different device or user.
