Failure backing up a single app cancels the entire backup

[t-m-w]

Upstream issue, or perhaps by design, but I am noting it here for awareness if nothing else, since we may need to work around it.

If a single app misbehaves, crashes, or is otherwise displeased when the framework tries to retrieve its backup data, the framework will cancel the entire backup, spoiling it for all other apps and data.

Example I observed with Orbot (with D2D patch, but appears to occur in other circumstances too; see related):

W BackupManagerService: agentDisconnected: the backup agent for org.torproject.android died: cancel current operations
W PFTBT   : Full backup cancel of org.torproject.android
W PFTBT   : Backup cancelled. package=org.torproject.android, cancelAll=true
I PFTBT   : Full backup completed with status: -2003

See UserBackupManagerService.java.

Related/same issue with com.qualcomm.qcrilmsgtunnel: #485

[grote]

The OS seems to intentionally set cancelAll to true for some reason. Ideally, we shouldn't need to work around this. Maybe you or someone could try a stock google backup agent D2D with orbot and see what happens there?

[t-m-w]

I'm not certain how to initiate any type of D2D migration of app data on stock Pixel devices, unfortunately.

Brief info dump:

I tried using the "Copy data" (from another device) feature to go from Pixel 4a (5G) to Pixel 7 Pro, and no app data was transferred for apps. Unless I am missing something, this appears to be by design. A link is shown at the bottom of the transfer page which says, "Some of your data may not transfer to your Pixel. Learn more", which in turn indicates that some data cannot be copied, including "App data (if the app doesn't use Android backup)". It's not displayed as an error or limitation of my environment, just an informational message.

OEMs may use D2D migrations, though. For example, based on its description, Samsung Smart Switch may use it (not tested):

Most app data will transfer, however any secure or encrypted data (i.e. WhatsApp chats) will not be transferred.

Screenshots from copying data for Pixel

[grote]

Did you try some more simple apps that would work in normal backup, e.g. Tickmate?

[t-m-w]

Unfortunately, no. At least not yet.

Their user documentation for Pixels does appear to explicitly state that it only supports copying data from apps that "support Android backup": Transfer data from an Android phone to a Pixel - Pixel Phone Help

And here's some relevant commentary on the subject, where it is speculated Pixel phones support this but not confirmed: Another Story of Backup and Restore In Android (12).

[t-m-w]

Tickmate worked fine for Copy Data, and it also worked even after I turned off backup to Google Drive. Others that should support D2D did not have their data transferred under any conditions.

It does say that the cable can be removed even before Tickmate is installed, so it must put its data in a staging area.

All tests cheetah (7 Pro) -> bramble (4a 5G) this time; was the other direction in my first comment.

[chirayudesai]

The OS seems to intentionally set cancelAll to true for some reason. Ideally, we shouldn't need to work around this.

But the world is not ideal, so let's do it!

[grote]

What may be happening is that there's a "pre-flight error" here: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/services/backup/java/com/android/server/backup/fullbackup/PerformFullTransportBackupTask.java;l=455;drc=2722d365c9b93adc88c14e55aaf6ffb54d47cda5

A first step may be to log the LOG_EVENT_ID_ERROR_PREFLIGHT ourselves with as much debug info as we can. Setting MORE_DEBUG to true would also be nice.

[grote]

I made a tiny app that reproduces the problem: https://gitlab.com/grote/backupagentcrasher