I think what happened is that it's the Nexus / Pixel portion of the company that decided this was a problem, and they did a good job of solving it for the stock OS as a value add over AOSP via added backup hooks in their forks of apps and an extra app providing some backup hooks.
Conversation
That's been slowly trickling into AOSP so it has been getting more complete. I'm not entirely sure how much stuff stored outside of app data is still missing backup hooks in AOSP. It's not actually very hard to implement at all, it's just hooks to load and save the data.
1
1
So, apps have to go out of the way to disable it for themselves, but privileged system apps need to go out of the way to do backup/restore for the non-app-based data storage, like Wi-Fi networks and other things like that stored 'somewhere' outside of the system apps themselves.
2
1
Replying to
yeah I figured it works something like that, it's pretty frustrating if you have to restore backups a lot
1
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.
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
Show replies