Backup does not work for most apps

[DDvO]

When trying to backup all my apps and data, only around 25% of them (e.g., 21 of 97) allegedly got backed up correctly
when Seedvault claimed "Backup finished".
For most of the others, in the backup status an orange warning symbol is shown and the text "Waiting to back up.." and for few remaining ones a red failure symbol is shown without text.

This appears to indicate that SeedVault is of rather little use.
I cannot even confirm that successful backup of the 25% actually worked fine, due to #682.
Certainly for some apps the backup is incomplete -
for instance, for the Signal and Photos apps success and a backup data size of 20 kB is reported, which is way too little!

Update: Part of the issue could be that when storage space runs out, the backup process wrongly claims "finished".

[grote]

What version of Seedvault are you running? Based on your description, it sounds outdated. Also, can you post the logcat export of the backup process?

[DDvO]

Thanks for your quick reaction.
I used whatever comes with the latest LineageOS 21.0, which is version 14-4.0, for both backup and restore attempts.
Here is the log file created by Seedvault, which BTW contains lots of needless clutter: seedvault-14-4.0-1718572684450.txt

[grote]

Do you have package names of some apps that are in "Waiting to back up.." still and could you also grab a log right after kicking off manual backup?

[DDvO]

So version 14-4.0 should be good enough?
BTW, where to find which is the most recent version and changelog?

The list of the apps "Waiting to back up..".
include, e.g., Aptoide, Charge Control, Contacts Storage, DB Navigator, Element, Evernote, F-Droid, K-9 Mail, Komoot, Mapy.cz, Messaging, Nova Launcher, Opera, Termux, TitaniumBackup, Windy, etc.
Anyway, they should be part of the log, along with their status.

I just deleted the backup on my source system and re-did it, resulting in this log seedvault-14-4.0-1718742954246.txt
Weirdly, Seedvault did another backup automatically two minutes later, resulting in seedvault-14-4.0-1718743139682.txt

BTW, the logs contain the worrying line:

06-18 22:21:21.729 13022 13022 E AndroidRuntime: java.lang.AssertionError: cash.z.ecc.android.bip39.Mnemonics$WordCountException: Error: 13 is an invalid word count.

I found in the below logs a couple of lines containing KeyValueBackupTask: Starting full backups for: with a list of app package names for which backup was attempted, with varying list sizes.

For instance for the Windy app, the log lines containing the package name no.nrk.yr are:

06-18 22:34:46.099  1376 18884 D KeyValueBackupTask: Starting full backups for: [im.vector.app, lineageos.platform.auto_generated_rro_product__, lineageos.platform.auto_generated_rro_vendor__, mattecarra.accapp, me.bluemail.mail, no.nrk.yr, org.calyxos.backup.contacts, org.chromium.chrome.stable, org.fdroid.fdroid, org.leo.android.dict, org.lineageos.aperture, org.lineageos.aperture.auto_generated_rro_vendor__, org.lineageos.aperture.frameworksbaseoverlay, org.lineageos.backgrounds, org.lineageos.eleven, org.lineageos.etar, org.lineageos.glimpse, org.lineageos.glimpse.frameworksbaseoverlay, org.lineageos.jelly, org.lineageos.lineageparts.auto_generated_rro_product__, org.lineageos.lineageparts.auto_generated_rro_vendor__, org.lineageos.lineagesettings.auto_generated_rro_product__, org.lineageos.overlay.customization.blacktheme, org.lineageos.overlay.customization.navbar.nohint, org.lineageos.overlay.font.lato, org.lineageos.overlay.font.rubik, org.lineageos.recorder, org.lineageos.settings.auto_generated_rro_product__, org.lineageos.settings.auto_generated_rro_vendor__, org.lineageos.setupwizard.auto_generated_rro_product__, org.lineageos.setupwizard.auto_generated_rro_vendor__, org.lineageos.updater.auto_generated_rro_product__, org.lineageos.updater.auto_generated_rro_vendor__, org.peakfinder.area.alps, org.protonaosp.deviceconfig.auto_generated_rro_product__, org.protonaosp.deviceconfig.auto_generated_rro_vendor__, stericson.busybox, tools.church.app, udk.android.reader]
06-18 22:34:52.981  1376 19079 I PFTBT   : Initiating full-data transport backup of no.nrk.yr token: 1844764875
06-18 22:34:52.990  1376 19240 D BackupManagerService: [UserID:0] awaiting agent for ApplicationInfo{327caee no.nrk.yr}
06-18 22:34:53.013  1376  1623 I ActivityManager: Start proc 19241:no.nrk.yr/u0a297 for backup {android/FullBackupAgent}
06-18 22:34:53.075  1376  3925 D BackupManagerService: [UserID:0] agentConnected pkg=no.nrk.yr agent=android.os.BinderProxy@54eb076
06-18 22:34:53.136  1376 19261 D BackupManagerService: Calling doFullBackup() on no.nrk.yr
06-18 22:34:53.746  1376  3925 I ActivityManager: Process no.nrk.yr (pid 19241) has died: bkup TRNB
06-18 22:34:53.783  1376 19079 I PFTBT   : Unbinding agent in no.nrk.yr
06-18 22:36:15.726  1376 20346 W PackageConfigPersister: App-specific configuration not found for packageName: no.nrk.yr and userId: 0
06-18 22:36:16.031  1376 20346 W PackageConfigPersister: App-specific configuration not found for packageName: no.nrk.yr and userId: 0
06-18 22:37:59.180  1376 25615 D KeyValueBackupTask: Starting full backups for: [im.vector.app, lineageos.platform.auto_generated_rro_product__, lineageos.platform.auto_generated_rro_vendor__, mattecarra.accapp, me.bluemail.mail, no.nrk.yr, org.calyxos.backup.contacts, org.chromium.chrome.stable, org.fdroid.fdroid, org.leo.android.dict, org.lineageos.aperture, org.lineageos.aperture.auto_generated_rro_vendor__, org.lineageos.aperture.frameworksbaseoverlay, org.lineageos.backgrounds, org.lineageos.eleven, org.lineageos.etar, org.lineageos.glimpse, org.lineageos.glimpse.frameworksbaseoverlay, org.lineageos.jelly, org.lineageos.lineageparts.auto_generated_rro_product__, org.lineageos.lineageparts.auto_generated_rro_vendor__, org.lineageos.lineagesettings.auto_generated_rro_product__, org.lineageos.overlay.customization.blacktheme, org.lineageos.overlay.customization.navbar.nohint, org.lineageos.overlay.font.lato, org.lineageos.overlay.font.rubik, org.lineageos.recorder, org.lineageos.settings.auto_generated_rro_product__, org.lineageos.settings.auto_generated_rro_vendor__, org.lineageos.setupwizard.auto_generated_rro_product__, org.lineageos.setupwizard.auto_generated_rro_vendor__, org.lineageos.updater.auto_generated_rro_product__, org.lineageos.updater.auto_generated_rro_vendor__, org.peakfinder.area.alps, org.protonaosp.deviceconfig.auto_generated_rro_product__, org.protonaosp.deviceconfig.auto_generated_rro_vendor__, stericson.busybox, tools.church.app, udk.android.reader]
06-18 22:38:04.965  1376 25835 I PFTBT   : Initiating full-data transport backup of no.nrk.yr token: 1275903637
06-18 22:38:04.968 15191 18465 I FullBackup: Perform full backup for no.nrk.yr.
06-18 22:38:04.971 15191 18465 D ApkBackup: Package no.nrk.yr with version 1100008042 already has a backup (1100008042) with the same signature. Not backing it up.
06-18 22:38:04.971 15191 18465 I BackupCoordinator: Get backup quota for no.nrk.yr. Is full backup: true.
06-18 22:38:04.978  1376 25965 D BackupManagerService: [UserID:0] awaiting agent for ApplicationInfo{f782224 no.nrk.yr}
06-18 22:38:04.995  1376  1623 I ActivityManager: Start proc 25966:no.nrk.yr/u0a297 for backup {android/FullBackupAgent}
06-18 22:38:05.047  1376  3889 D BackupManagerService: [UserID:0] agentConnected pkg=no.nrk.yr agent=android.os.BinderProxy@5f317fd
06-18 22:38:05.074  1376 25990 I file_backup_helper:    Name: apps/no.nrk.yr/_manifest
06-18 22:38:05.074  1376 25990 D BackupManagerService: Calling doFullBackup() on no.nrk.yr
06-18 22:38:05.075 15191 18465 D FullBackup: Initializing OutputStream for no.nrk.yr.
06-18 22:38:05.566 15191 18465 I BackupNotificationManager: 262/354 - 74% - Yr (no.nrk.yr)
06-18 22:38:05.818 15191 18465 I FullBackup: Finish full backup of no.nrk.yr. Wrote 1708032 bytes
06-18 22:38:05.871  1376  3889 I ActivityManager: Process no.nrk.yr (pid 25966) has died: bkup TRNB
06-18 22:38:05.915 15191 18465 I NotificationBackupObserver: Completed. Target: no.nrk.yr, status: 0
06-18 22:38:05.915  1376 25835 I PFTBT   : Unbinding agent in no.nrk.yr
06-18 22:38:11.756 15191 19120 I NotificationBackupObserver: Showing progress notification for no.nrk.yr 262/354
06-18 22:38:18.063 15191 15201 W oltys.seedvault: ApkAssets: Deleting an ApkAssets object '<empty> and /data/app/~~qgqlHFHzDhE8eaOGh8X1Jw==/no.nrk.yr--TrjaVj6kpTjH_YttzzyJg==/base.apk' with 1 weak references
06-18 22:38:18.063 15191 15201 W oltys.seedvault: ApkAssets: Deleting an ApkAssets object '<empty> and /data/app/~~qgqlHFHzDhE8eaOGh8X1Jw==/no.nrk.yr--TrjaVj6kpTjH_YttzzyJg==/split_config.arm64_v8a.apk' with 1 weak references
06-18 22:38:18.063 15191 15201 W oltys.seedvault: ApkAssets: Deleting an ApkAssets object '<empty> and /data/app/~~qgqlHFHzDhE8eaOGh8X1Jw==/no.nrk.yr--TrjaVj6kpTjH_YttzzyJg==/split_config.xxhdpi.apk' with 1 weak references

which appears to indicate that the backup succeeded, though the app is still listed as "Waiting to back up...".

[grote]

It looks like the no.nrk.yr app was backed up successfully indeed and 1708032 bytes written. Unfortunately, there's no hint in the log why the backup status of the app wasn't updated. It looks like this app should be called Yr. Can you post a screenshot of this app's backup status?

[DDvO]

As can be seen also here, user-level debugging of Seedvault is a pain in the ass, already because its diagnostics is a mess.
You should really add to-the-point status/error reporting and logging.

Right, the user-facing name of the no.nrk.yr app is Yr.
I just re-did the backup. This time, the backup status of Yr is success (1.8 MB).
Yet for most other apps, as before, "Waiting to back up..." is shown (as usual, without further info).
And again for a couple of apps failure is reported (as usual, without further info to the user).

[grote]

You should really add to-the-point status/error reporting and logging.

We really should? Could you dial down your entitlement please? Also you might want to read one of the many articles on the subject. Here's random onea I fished out of the internet: https://mikemcquaid.com/entitlement-in-open-source/ https://jacobtomlinson.dev/posts/2022/dont-be-that-open-source-user-dont-be-me/
I can't really find the paycheck from or SLA with Siemens 🤷

This time, the backup status of Yr is success (1.8 MB).

Ok all good then.

Yet for most other apps, as before, "Waiting to back up..." is shown (as usual, without further info).

Could this be related to you running out of space on your backup destination? See #698

If not, I need a screenshot of the backup status screen showing those apps and a complete log from the latest backup run where those apps did not get backed up.

[julianfoad]

Let's try to move forward by clarifying what's needed for a "solution" to this issue. I had the same experience and frustration.

The overall problem seems to be: It claims it finished, but the status list looks terrible: only 25% success, 75% failures. "This appears to indicate that SeedVault is of rather little use."

In reality this seems to be a mixture of real problems and perception.

Part of the problem comes from the various exclusion criteria, such as:

• "Apps that do not allow data backup" --> D2D mode Option to back up all apps by pretending to be a device to device transport #165 seems a promising solution; when I enable it (in 14.4-0) then a much higher proportion of apps are backed up. This is probably the biggest single factor.
• The per-app "quota" (which I didn't understand until reading Is it possible to change the backup quota? #183 and Android docs)

Part of the problem comes from the way the overall result status is presented, both in summary and in the status list. The individual statuses in the list can be understood in these different categories:

• Success (green tick mark);
• Genuine problems (such as storage space full, although that's more of an overall failure);
• Unexplained/absent statuses ("red failure symbol without text" List of apps that always show backup errors (use for inherently broken apps only) #147 Question: Red exclamation next to app #214; and for some apps I see no icon and no text, in LineageOS 21, SV 14.4-0, experimental D2D mode enabled);
• Not backed up for valid reasons (not attempted, no data, quota exceeded) but are shown with "warning" or "failure" indications giving the impression of problems to be solved, when really it's working correctly.

A solution might include:

• The overall "finished" message could be more helpful by saying something at least a little more like "finished with errors" versus "finished with no errors".
• Show a status summary, perhaps something like: "X apps FAILED; Y apps backed up; Z apps omitted (not attempted, no data, quota exceeded, or manually excluded)".
• The "Waiting" message should be changed to something like "Not attempted", after the backup has run once and this app was not requested by the backup system: see The Backup Message 'Waiting to Backup' is Confusing #234
• For statuses "not attempted", "no data", and maybe "quota exceeded": show a different, less scary, icon; and ensure the text hints that it is not an error, using language like "omitted because...".
• Nice to have: Grouping the status list by status category (backed up; omitted; failed).
• Bug fix: Ensure every status has an icon and explanatory text. (see "Unexplained/absent statuses" above)

Does that make sense, and fit with the overall context?

[DDvO]

@grote

You should really add to-the-point status/error reporting and logging.

We really should? Could you dial down your entitlement please? Also you might want to read one of the many articles on the subject. Here's random onea I fished out of the internet: https://mikemcquaid.com/entitlement-in-open-source/ https://jacobtomlinson.dev/posts/2022/dont-be-that-open-source-user-dont-be-me/ I can't really find the paycheck from or SLA with Siemens 🤷

Looks like you misunderstood and prejudiced the context and motivation of my feedback to this project.
I do not act here on behalf of a company like Siemens that might throw money or manpower at it, but as an
individual senior IT developer, researcher, consultant, privacy advocate, and user with personal interest in Android.
I have more than enough SW (mostly OSS), consulting, and standardization projects to drive or actively contribute to.

Hoping that Seedvault could be used as successor/alternative to the dated and inactive Titanium Backup,
I recently spent about 2-3 work days of my very limited spare time trying it out and providing feedback.
Given that the project is around for more than 5 years and the way it is advertised and included in major custom ROMs,
one would have expected that it has some maturity and can be used productively,
and I got very disappointed finding out that at least in my experience basically nothing about Seedvault works fine.

Still, as I'm a patient person trying to help out, I've attempted giving feedback in the hope that at least
in the long run users will have a better experience with Seedvault, having a Google-free backup solution.

I suppose the vast majority of potential Seedvault users just tried it once and turned away without providing any feedback to the project.

Yet for most other apps, as before, "Waiting to back up..." is shown (as usual, without further info).

Could this be related to you running out of space on your backup destination? See #698

No, it happens also when there is enough storage space.
If Seedvault had useful diagnostics, you wouldn't even need to come up with theories about what the reason
might be and ask such questions, because to-the-point error messages and logs would simply tell the actual reason.

If not, I need a screenshot of the backup status screen showing those apps and a complete log from the latest backup run where those apps did not get backed up.

Don't you see how needlessly inefficient this type of interaction between users (like me) and developers (like you) is?
This could have been done much quicker and with extremely little effort if Seedvault provided to-the-point error reports.

I really wonder why you exhibit such reluctance on the most fundamental feedback and advice
that I have been given to your project right from the beginning and have repeated several times.
The very reason why I wrote "You should really add to-the-point status/error reporting and logging."
is that it clearly would be that tremendously helpful, while - as mentioned - the current way of interactive
diagnosis with bad tooling is a pain in the ass for all parties involved and neither effizient nor effective.
Yet for some reason, you apparently do not want to see this.

The fact that Seedvault does not have useful error messages and dedicated logging (rather than just relying on
that dumb general Android system logs that is full of useless clutter and painful to use even for experienced folks)
pretty sure is a major blocking point for the progress of the project.
It severely hampers users, their interaction with developers, and I'd bet also the internal development process.

[DDvO]

@julianfoad thank you for your constructive response!

Let's try to move forward by clarifying what's needed for a "solution" to this issue. I had the same experience and frustration.

👍

The overall problem seems to be: It claims it finished, but the status list looks terrible: only 25% success, 75% failures. "This appears to indicate that SeedVault is of rather little use."

In reality this seems to be a mixture of real problems and perception.

Part of the problem comes from the various exclusion criteria, such as:

* "Apps that do not allow data backup" --> D2D mode [Option to back up all apps by pretending to be a device to device transport #165](https://github.com/seedvault-app/seedvault/issues/165) seems a promising solution; when I enable it (in 14.4-0) then a much higher proportion of apps are backed up. This is probably the biggest single factor.

* The per-app "quota" (which I didn't understand until reading [Is it possible to change the backup quota? #183](https://github.com/seedvault-app/seedvault/issues/183) and [Android docs](https://developer.android.com/identity/data/backup#Choosing))

These two options sounded very promising, but:
I had enabled both of them pretty early in my experiments, and still get just some (alleged) 25% app coverage.

Part of the problem comes from the way the overall result status is presented, both in summary and in the status list. The individual statuses in the list can be understood in these different categories:

* Success (green tick mark);

* Genuine problems (such as storage space full, although that's more of an overall failure);

* Unexplained/absent statuses ("red failure symbol without text" [Some apps show backup errors #147](https://github.com/seedvault-app/seedvault/issues/147) [Question: Red exclamation next to app #214](https://github.com/seedvault-app/seedvault/issues/214); and for some apps I see no icon and no text, in LineageOS 21, SV 14.4-0, experimental D2D mode enabled);

* Not backed up for valid reasons (not attempted, no data, quota exceeded) but are shown with "warning" or "failure" indications giving the impression of problems to be solved, when really it's working correctly.

These categories look sensible.
Yet for nearly all non-success cases, like you, I experience no error message or explanation.

A solution might include:

* The overall "finished" message could be more helpful by saying something at least a little more like "finished with errors" versus "finished with no errors".

Yes, and it would be good to also give the app size (in addition to the data size), as suggested here.

* Show a status summary, perhaps something like: "X apps FAILED; Y apps backed up; Z apps omitted (not attempted, no data, quota exceeded, or manually excluded)".

* The "Waiting" message should be changed to something like "Not attempted", after the backup has run once and this app was not requested by the backup system: see [The Backup Message 'Waiting to Backup' is Confusing #234](https://github.com/seedvault-app/seedvault/issues/234)

* For statuses "not attempted", "no data", and maybe "quota exceeded": show a different, less scary, icon; and ensure the text hints that it is not an error, using language like "omitted because...".

* Nice to have: Grouping the status list by status category (backed up; omitted; failed).

* Bug fix: Ensure every status has an icon and explanatory text. (see "Unexplained/absent statuses" above)

Does that make sense, and fit with the overall context?

Sounds good!

Plus: remove from the app log output all the needless bulky mess not directly about the progress of Seedvault runs.
And maybe add useful intermediate checkmarks and status infos, at least once per app being handled.

[eylenburg]

I have a bunch of apps saying "app reported no data for backup." This includes apps like Bitwarden, Element, kDrive or Mega where I would have definitely expected some data to be there. I have enabled device to device backups in the expert settings. Couldn't find this message in any of the Github issues anywhere.

Also some apps have a green tick and then say the storage size (e.g. "Thunderbird: green tick (36 MB)") and some don't have the storage size (e.g. "Whatsapp: green tick"). Does the latter mean nothing was actually backed up?

[grote]

I have a bunch of apps saying "app reported no data for backup." This includes apps like Bitwarden, Element, kDrive or Mega where I would have definitely expected some data to be there.

The way the system backup API works is that apps are responsible to deliver data for backup and they can exclude data from backup based on certain rules. If those apps don't give us any data, this should be reported to the developers of those apps and request they support the system backup API properly.

"Thunderbird: green tick (36 MB)")

But for Thunderbird did it also say "app reported no data for backup." ?

some don't have the storage size (e.g. "Whatsapp: green tick"). Does the latter mean nothing was actually backed up?

WhatsApp is known to show green, but doesn't actually back up anything. They have their own internal backup mechanism.