Feature request: Backup and restore settings

[lukexodus]

Often times when Ankidroid crash, most of how I fix it is through clearing its data or uninstalling and reinstalling Ankidroid. Please add an option to backup and restore settings so that we don't have to always set the desired settings every time we fix Ankidroid crashes.

[david-allison]

Hi, thanks for the request!

As an aside: Could you report these crashes? I spent a lot of time last year fixing what I believed to be pretty much all of the crashes. I haven't been actively bugfixing for a while, but if we've introduced bugs, please let us know so we can fix them.

[lukexodus]

I'm sorry I accidentally closed it 😅...

david-allison-1 I've set the settings to automatically send the crash reports. Do I have to take other steps for this one?

The most recent crash is when I've opened Ankidroid after I checked the "Automatic Synchronization" setting under "General." I don't know if this is the exact reason but I don't think it wasn't a coincidence either.

[david-allison]

Thanks! Could you go to Settings - Advanced - About AnkiDroid - Copy Debug Info and paste it here.

[david-allison]

To keep the discussion on the issue at hand: I agree

It seems reasonable as an advanced option, but allowing import allows a user to modify of the settings outside their accepted parameters, which can be an additional source of bugs/crashes.

We currently rely on UI-based validation, so this will likely require effort to get 'right', or will need to be in a DEBUG setting.

I feel gestures and keyboard shortcuts are the "main" candidates if we want to do this piecemeal, as they require a fair amount of time to setup.

Android's backup mechanism may also be a candidate for this.

[lukexodus]

AnkiDroid Version = 2.15.6

Android Version = 8.1.0

Manufacturer = vivo

Model = vivo 1811

Hardware = qcom

Webview User Agent = Mozilla/5.0 (Linux; Android 8.1.0; vivo 1811 Build/OPM1.171019.026; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/70.0.3538.110 Mobile Safari/537.36

ACRA UUID = 35156451-131f-4dec-8f31-2c9b5e0a69f7

Scheduler = std2

Crash Reports Enabled = true

DatabaseV2 Enabled = true

[david-allison]

@shiideyuuki I've moved the discussion to #9764 and am asking questions there.

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[krmanik]

To reduce cost on AnkiWeb, may be we should consider this https://developer.android.com/guide/topics/data/backup

Backup options

Android provides two ways for apps to back up their data to the cloud: Auto backup for apps and Key/Value Backup. Auto Backup, which is available on Android version 6.0 and higher, preserves data by uploading it to the user's Google Drive account. Auto Backup includes files in most of the directories that are assigned to your app by the system. Auto Backup can store up to 25 MB of file-based data per app. The Key/Value Backup feature (formerly known as the Backup API and the Android Backup Service) preserves settings data in the form of key/value pairs by uploading it to the Android Backup Service.

Generally, we recommend Auto Backup because it's enabled by default and requires no work to implement. Apps that target Android version 6.0 or higher are automatically enabled for Auto Backup. The Auto Backup feature is a file-based approach to backing up app data. While Auto Backup is simple to implement, you may consider using the Key/Value Backup feature if you have more specific needs for backing up data.

Note: If your app doesn't have a backup mechanism for app contents and the size of your app contents is unlikely to exceed the 25 MB limit, then Auto Backup may be sufficient for your needs.

[mikehardy]

I dislike this [edit for clarity: by "this" I mean using google prefs backup services] because it won't be truly multi-platform, and also it ties us to a second "vendor" (the first and unavoidable one being AnkiWeb, this would be a second: google). One of the things that is neat about AnkiDroid is that right now it's google-agnostic, we don't rely on anything from google with the sole exception of analytics which is completely opt-in, only used for light "feature steering", and chosen just because of scale (huge) and cost (free).

[krmanik]

Then we should use Ankiweb to store prefs.json. The file size for storing all the prefs in settings will be/may be less than 10kb. Also this is discussed in this issues #9905 . So, my implementation idea will be like this (also already discussed in https://github.com/ankidroid/Anki-Android/issues/9905#issuecomment-1016474096)

1. An option in Advanced settings to export all the settings prefs to a json file
2. Another option to import the json file, which update the prefs on new AnkiDroid install
3. Option to save it to collection.media with _ prefix name e.g. _ankidroid_prefs.json so it will be sync with Ankiweb.
4. Also the settings needs to check which is common in AnkiDesktop and AnkiDroid so changes at one device will update the another device.
5. The prefs implementation will be similar to deck/addons config storage and update.

[mikehardy]

🤔 that means we will now have a lot of "accounting" to do to make sure that the prefs are in sync etc Why not just store the prefs directly in collection config and use that as the SharedPreferences implementation (that is, write a sort of 'AnkiCollectionSharedPreferences' sub-class of SharedPreferences that:

1- determines if prefs exist in collection config location to begin with, a) if they do, just use them as the preferences backing store b) if they do not, migrate prefs to collection config location, then 1a ?

So 1b is temporary code but there is no import/export/are-we-insync/UI/UX work to do ? Is this even possible given what we know about collection config etc? I think it is - my working assumption is that our preferences are not that large in number and do not contain that much data per preference

[krmanik]

AnkiCollectionSharedPreferences will be much better to reduce the complexity. I will implement considering this. Thanks

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[dae]

Please don't use media files for frequently changing content - small key/values are better stored in the collection config as Mike suggested. Note that not everything can be stored there - the sync key, profile config and per-device settings will need to be stored elsewhere.

[BrayanDSO]

I may get to this next month.

So I'd like to ask you @dae if it is fine to save a bunch (we have a lot of prefs) of key/values pairs on the collection.

The keys would have a prefix like ankidroid_ and the values overall should be small.

[dae]

That should be ok, but the current sync protocol sends the entire config on each sync, so until that gets addressed, it would be nice if you could try to keep things small by:

a) using camelCase names and a short prefix (eg AnkiMobile uses things like 'amSomeOption') b) if possible, avoid persisting a value until the user changes the default setting (eg if the default of 'amSomeOption' is 5, it starts off not being in the config, and only gets written the first time the user changes it. No need to worry about clearing it again when it's changed back to the default). This can be handled by adding accessors for each pref, that return the default value if it's missing or set to an invalid value c) avoid persisting any large values like lists over 100 items, etc

[mikehardy]

Also note that device-specific items should not be persisted, those will always be lost. The only things that should be persisted in collection are things that are truly applicable to the whole collection that the user will definitely want on each device. This may not include certain display prefs like dark mode follows system, themes, etc (perhaps they want that different on different devices?). It may require opinion decisions to come up with the set of things to keep in android prefs vs collection config

[BrayanDSO]

Probably the first thing to be done is what the issue is asking: a way to backup/export and restore/import preferences in a JSON or whatever format that's easy to handle on Android. For backup/restore, I think that all prefs should be included.

Then yeah, a way to sync preferences across devices for the "more universal" preferences (currently I guess this fits only the Reviewing and Controls prefs)

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically