Full Backup (i.e. via D2D) kills apps, including always-on VPNs, and they do not typically get restarted

[t-m-w]

Perhaps unexpectedly, AOSP sends a kill signal to an application's main process after a full backup has been completed rather than before. But either way, the unfortunate result is that apps which run with a single process may remain affected until the user intervenes. This includes apps that are expected to stay running, like always-on VPN apps. A user's device could lose connectivity entirely, which is particularly problematic if the backup happens while the device is unattended, since the user would not know anything was wrong until they looked at their device. (Also of note, in the case of a "lockdown" VPN, if Seedvault is performing a network backup, this will likely cause the backup to fail.)

A workaround is to exclude affected apps from the backup, but this is not ideal.

Here are some links I gathered while looking into this issue that may be informative:

• Killing of the application process, today
• Original justification (when just for restore)
• First commit for full backup infrastructure
• Default full backup mechanism
• Binding of the backup agent

And here's my original comment regarding this issue, before I'd started researching the cause:

I've noticed some issues lately, likely related to D2D backups, that are going to be frustrating for users. For example, some VPNs are not getting automatically restarted anymore after they are backed up, even when set as Always-On VPNs. I don't think this is specific to app-backup-v2, but since D2D is the default and only option now, we should be aware of it. Likely I will want to copy/paste some of this comment into another issue or two somewhere later.

Known-affected VPNs:

• Mullvad 2024.4 from F-Droid. (2024.3 is fine.) It needs to be manually started after a backup, from that version forward.
• WG Tunnel 3.5.2 from F-Droid. It needs to be manually started after a backup.
• Orbot 17.3.2-RC-1-tor-0.4.8.12. It needs to be manually started after a backup.
• Wireguard 1.0.20231018. It needs to be manually opened after a backup.

Some other apps seeing unwanted effects:

• Auxio 3.5.3 from F-Droid. It loses its current playing track and position and shuffle state (probably just everything, killed without saving it; force-stop does the same thing).

I'll keep an eye out for others.

The VPN issues are especially notable, since for some configurations, the device might lose network connectivity in the middle of the night or day. If the backup takes place over the VPN, that could mess up that backup. The simplest suggestion for now is of course to exclude the VPN app from backups entirely.

On second thought, as far as VPNs, this could be an AOSP bug, since always-on VPNs should get restarted regardless in my opinion.

Anyway, my hope is that issues like this can often be addressed in the apps themselves, especially in the case of Mullvad for example, where we have a known-working and known-broken version for comparison.

[grote]

Interesting that backupInForeground doesn't seem to get respected. It is false by default.

Maybe this is only when the system requests the backup itself and not when we request it with own scheduling?

[grote]

Also relevant here: android:killAfterRestore="true"