Backup APKs of apps not being backed up #65
Comments
chirayudesai
changed the title
|
At the moment #64 does not back up APKs of apps that:
Right now, in #64, backing up the APK and writing metadata about the backed up app are done together. First I did it early, so we included metadata about a bunch of apps we didn't actually back up, so they were shown as failures when restoring. Then I moved it to a place where we were sure the app got backed up. This got rid of the failures, but excludes unused apps (1) or apps over-quota (2). A possible solution could be to break up APK backup and metadata writing a bit more, maybe have two types of metadata writes: one after the APK got backed up and one after the app got backed up. We would need to remember the difference in the metadata, so that we re-install apps without data, but don't give the impression that we have a backup of the data as well. In the restore screen, we might still show those data restores as failures to make transparent that we couldn't restore data for those apps. So this takes care of (1) and (2), but it doesn't solve (3), because for apps that opt-out of backup, our code will not even be called. To solve this, we probably need a parallel backup mechanism that takes a list of all opt-out apps and at least backs up their APKs. Ideally this could be hooked into the regular backup schedule, but I fear we will need our own job scheduler service for this. Alternatively, we could add all apps whose APKs didn't get backed up through the normal means to the parallel mechanism, if we need one anyway. |
|
Interesting, considering this option opens up even more possibilities.
For 1, it's straightforward, and can be added straight away once we have a technical solution A parallel mechanism sounds good and a way to solve this issue, but at the same time could lead to complications. One thing I can think of - add some more special case handling when |
On my personal phone I saw this for one app, but F-Droid and Nextcloud for example had a similar issue. This normally happens when developers don't care about backup and don't take measures to stay under Google's 25 MB limit. Normally an app shouldn't get close to this. I don't think increasing the quota will help. We already doubled Google's quota. Apps that don't care will just amass data until they are above whatever quota. What we could do though is add a field to the metadata reflecting the backup status of each app, so it becomes transparent to the user and the app could eventually fix it. These could be for example:
We could then show this in a meaningful way to users to hopefully make things less confusing.
We need to be careful here as the AOSP backup code is very under documented and can have surprises. For example, apps can notify the system that data changed and then only a backup of that app is triggered. I've also seen |
chirayudesai
changed the title
Makes sense.
Looks good. I think that pretty much covers all cases, and if not, more could always be added I guess.
One thing that might help is having different failed icons / colors. |
This should also affect apps that have other errors during the backup process, but it does not affect apps that opt-out of backup completely. First part of seedvault-app#65
This should also affect apps that have other errors during the backup process, but it does not affect apps that opt-out of backup completely. First part of seedvault-app#65
|
This has been fixed in the develop branch, so can probably be closed now or when merged into master. |
The system doesn't backup any apps which don't have data, which would include apps which haven't really been used.
This is with / after APK backups.
For example, I had wireguard instaleld on my phone but it didn't get backed up because I hadn't added any server entries to it (Though I had definitely launched it after install)
I would've still liked to have it backed up though, as I wanted the app present for when I do end up needing it.
Having the APK for thsi backed up and restored would be nice, as to the user it's an app they had on the older phone and don't on the newer phone after restore.
The text was updated successfully, but these errors were encountered: