* We've had a love/hate relationship with the combination of
SAF + Nextcloud app + Nextcloud server
* SAF is quite limiting, and that causes it's own issues
* On top of that, Nextcloud app has it's own issues. We've
even sent patches for some things, but there's only so much one can do
https://github.com/nextcloud/android/pulls?q=is%3Apr+author%3Agrote
* With the DAVx5 WebDAV support, it seems to work better.
* However, most recently a server side change broke things entirely, with either apps
https://github.com/seedvault-app/seedvault/issues/490#issuecomment-1368032414
* Due of all of this, it just leads to a bad backup experience.
As such, let's just say this is not recommended at all entirely
* Hopefully in the future we'll be able to support more options
Change-Id: I0b46dd11df7c31606131bf311583fe4777536463
* Pressing "Backup now" should not just ignore you when it's not actually
enabled
* Add a toast message telling you it's not enabled
Fixes: #390
Change-Id: I5d698a244652e094b0acfc42cdea017a0af9a20b
* New SetupWizard uses external/setupdesign (sud) and
external/setupcompat (suc) to achieve the desired looks
* It prevents proper previews when included in any app, though, so
we better try achieving the same by manually styling the activities
for 12
* This patch mimics the design by applying styles similar to the ones
from sud, sometimes reusing parts taken from there
Change-Id: Iccf588e5239aeb00645f97b095910986f32c52d0
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.
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
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.
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.
Outside of SetupWizard restore, we don't offer to set up an account,
because we don't know if one already exists and the app was locked with
a passcode.
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.
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.
