Conversation

Replying to
The general issue with system data is that the backup service is an app-based implementation, and there's important data outside of what's stored in apps. So, privileged system apps like Settings actually have to set up hooks that know how to backup / restore the information.
1
Replying to and
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.
1
Replying to and
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
Replying to and
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
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
Replying to and
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
Replying to and
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
Replying to and
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
Replying to and
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
Show replies