yeah I figured it works something like that, it's pretty frustrating if you have to restore backups a lot
Conversation
oh by the way, can the system be modified to ignore the "no backups" app key? or would this just break most of the apps that set it?
1
Replying to
You can probably do that very easily. If it's backing up and restoring on the same hardware, I also doubt that it's going to break much. App developers do often have a valid reason for wanting to blacklist data from backups but they're just super lazy and disable it completely.
2
1
So for example, Chromium has a sync implementation. It disables Android backups for everything covered by the sync implementation and has custom hooks to backup / restore the subset of the data not covered by sync that they've deemed should still get backed up.
1
1
Problem: if you're using Chromium without Play services or don't want to use Google's backup service, that's not available, but Android backups only cover the tiny subset of data not covered by sync that they've explicitly decided to back up. Unresolved issue for Vanadium.
1
1
It does make a lot of sense to blacklist caches, because it's a huge waste to back them up, and to blacklist things like login tokens or other data that can / should be regenerated. Problem is you hand app developers something like this and they take the path of least resistance.
1
1
Android SDK lint wants you to explicitly figure out what should and shouldn't be backed up, and I think one reason devs disable it outright is the SDK lets them know they should do something and the easiest thing to do is fully disabling it + silencing 1 lint about disabling it.
1
1
If the SDK didn't consider it a bad practice to not explicitly do something about it, most apps would just leave it in the default fully enabled state, which would mostly be better... but not entirely, since you would definitely get problems with non-portable data, etc.
1
1
The experience they want is magically moving over everything to your brand new phone right after you've gone through the setup wizard. Since it's designed around portable backups, there's supposed to be care taken to actually make that happen properly.
1
1
Also, it's based on app id + signature, not just app id, so you can't directly use it to migrate data from one build of an app to another signed with a different key. I use adb backup + edit backup with a tool + adb restore to deal with that sometimes.
1
1
At one point I had to migrate from the unmaintained FreeOTP to a fork of it that was being actively developed and published via Play, and that's how I dealt with it since the data storage was still compatible. Really wish everything just had U2F/FIDO2... TOTP is srsly annoying.
My U2F/FIDO2 setup is that I use my Trezor, so the whole house could burn down and I can just buy a new Trezor and restore the seed phrase from metal plates. If it was just U2F I wouldn't have bothered but it's a nice little extra bit of functionality from a hardware wallet.
1
2
I also have SSH and GPG keys via the Trezor functionality but I don't use them for anything aside from a form of fallback.
Too annoying to authorize each SSH request, and I'm phasing out of my usage of GPG anyway, so rotating to a new key derived from a seed phrase is unlikely.
1
1
Show replies
Replying to
this is one of the reasons i don't use phone based OTP and just store the tokens in my password manager directly. stupid and counterproductive but availability is more important to me than almost anything else
1