Currently translated at 100.0% (112 of 112 strings)
Translated using Weblate (Russian)
Currently translated at 98.2% (110 of 112 strings)
Co-authored-by: Nikita Epifanov <nikgreens@protonmail.com>
Translate-URL: https://hosted.weblate.org/projects/calyxos/seedvault/ru/
Translation: CalyxOS/Seedvault
This commit also refactors the code in SettingsFragment and moves it into the SettingsViewModel.
The UsbMonitor turned out not to be reliable in determining changes to USB storage, so it was replaced with a ContentObserver which works for other storage types as well.
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 already don't run instrumentation tests in CI,
so we should at least compile them to catch any breakage there.
This is important as they don't even get compliled when building and
installing the app with Android Studio.
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 an app fails to install during restore, we offer the option to manually install it.
If this doesn't happen with the same app store,
it is likely that the installed app will have a different signature (e.g. Aurora vs. F-Droid).
If the signature doesn't match, the data restore will fail.
Therefore, we attempt to let the user only use the same store for re-install.
There's a known issue that F-Droid doesn't report the proper package name:
https://gitlab.com/fdroid/fdroidclient/-/issues/2085
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.
