Backup and restore settings, closes #839

[harshad1]

This PR addresses #839. I have liberally borrowed from OpenLauncher/BackupHelper

This PR now does not export a zip of the shared preference XML files (as openlauncher does). Instead, the preferences are exported as a JSON.

[harshad1]

@gsantner This works, but we need to review strings etc

[gsantner]

what do you think of adding SearchOrCustomDialog after file selection?

Data / Data +Settings / Settings

and for data, also select & add second folder recursive to zip.

I made impression users are interested in data backup too, even more than settings backup.

[harshad1]

I think data backup etc is best handled by an external app. For example, it's pretty easy to compress a folder using any file manager app. Feb. 18, 2021 01:03:22 Gregor Santner <notifications@github.com>:

…

what do you think of adding SearchOrCustomDialog after file selection? Data / Data +Settings / Settings and for data, also add the notebook folder recursive to zip —

[gsantner]

btw, the password is not contained in the export right (->keystore)? If so, we should strip that one

--->

ok just tried it, yes al credentials are exported. hmm not really good I would say.

[harshad1]

btw, the password is not contained in the export right (->keystore)? If so, we should strip that one

Ah good catch. I will address this

[gsantner]

basically we need a file::readLines().grep(!.encryption.)

@opensource21
Is it enough to decrypt with these two values? Just recall we (try to) store something in android's key storage, outside of app files/prefs.

[harshad1]

@gsantner Actually I am not sure why this is happening

As far as I can tell, the password should be removed from plaintext as soon as it is written. i.e. it should never be in plaintext

markor/app/src/main/java/net/gsantner/markor/activity/SettingsActivity.java

Line 251 in c1c8d21

prefs.edit().remove(key).commit();

[harshad1]

IMO, a much cleaner solution would be to use a regular dialog to set the password. That way it is never stored in plaintext and we don't have to do this delete after storing in password manager thing.

[harshad1]

@gsantner @opensource21 I think we are good to go :)

[gsantner]

I'm sorry that I have to block this still, but it does not work. Tried it.

• Set 22 as value just above the backup settings. exited app to make sure it saved the 22.
• then made backup
• Changed to 10, exited again to make sure it's saved and not pending.
• Then restored the backup. Checked settings and it's still at 10 - it should be 22 now.
• I also exited / restarted the app multiple times after loading the backup - the value is still at 10, so backup-restore didn't do anything.

https://user-images.githubusercontent.com/6735650/112771640-1da1c080-902d-11eb-9e0e-28bf076ee997.mp4

a.mp4

This is probably the price of converting back-and-forth formats, potential loss of information.

[harshad1]

For some reason, the .apply() does not appear to consistently apply the results before exit() after the recent changes. I have reverted to .commit()

@gsantner could you check importing now?

[harshad1]

This is probably the price of converting back-and-forth formats, potential loss of information.

To be clear, the issue was not data loss (all data appears to be preserved with 100% fidelity), but that .apply() would not finish writing to disk before sys.exit()

This is fixed now

[harshad1]

It appears we may not even need the system exit now that we are using system APIs to restore the settings. I have removed the exit, and everything seems to work great. Could you test and confirm?

[harshad1]

After much testing, I have decided that I agree with @gsantner and that we should store the file type as strings rather than indices. I will be making these changes later today.

[gsantner]

OK as you prefer, if you think indices is good enough, also OK if it works

[harshad1]

Switched all type formats to strings

[gsantner]

Note, this is how the format is saved now in the end: