Open Bug 1808763 Opened 3 years ago Updated 29 days ago

Allow backups once again

Categories

(Firefox for Android :: General, enhancement)

All
Android
enhancement

Tracking

()

People

(Reporter: csadilek, Unassigned)

References

Details

From github: https://github.com/mozilla-mobile/fenix/issues/16306.

Accompanying issue to Pull https://github.com/mozilla-mobile/fenix/pull/16305


What is the user problem or growth opportunity you want to see solved?

Users expect Android's backup and restore feature to "give them back" their app data upon migrating to a new device.
Rivaling browsers such as Chrome (or Safari on iOS) automatically carry over user data. This process seems seamless to the average user who does not know how tightly coupled Chrome's profiles are to a user's Google account ("Is just works" with Chrome).

Firefox Mobile currently just loses user data upon changing devices if not signed in to the sync service. The Mozilla-proprietary "sync" feature - which is heavily promoted - requires users to once again provide login data on their new devices and currently does not sync their collections (see https://github.com/mozilla-mobile/fenix/issues/4424)

Technical
App developers can opt out of the Android backup system by setting allowBackup=false in their AndroidManifest.xml (see Enabling Auto-Backup ), as has been done for Fenix in 28ee6ddc21865f5d68301363620d62a3e50732c4
(Following discussion in https://github.com/mozilla-mobile/fenix/issues/4072 )

The app data backup-restore mechanism serves two purposes:

  1. Restore app data upon migration to a new device
    For most Android devices, this will be done automatically via Google's "GMS backup transport", but others might implement their own backup transport.
    See https://developer.android.com/guide/topics/data/testingbackup#HowBackupWorks

  2. adb commands
    Give agency to users to (partially) backup/restore application data via adb commands

Not everyone wants to use Mozilla's sync feature. When migrating devices (which is the most common usecase for Android's backup feature), the much better option is to have your settings and bookmarks "automagically" re-appear.

Also note: This does not have to clash with the Mozilla sync feature. It would be even better if the signed-in state of the Mozilla account was automatically restored with a migration as well.

How do you know that this problem exists today? Why is this important?

https://github.com/mozilla-mobile/fenix/issues/4424
https://github.com/mozilla-mobile/fenix/issues/2080 (and duplicates)
https://github.com/mozilla-mobile/fenix/issues/417

Who will benefit from it?

  • Users who "lost" all their browsing data when switching devices and swore "never again" and simply went back to Chrome.
  • Users switching between different flavours of Firefox Mobile (backup files are currently not bound to a signature)

Issues yet to fix

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Many Android ROMs do have a solid backups actually using Seedvault (this is addressing comments on GitHub), you can also enable just encrypted backups: https://github.com/seedvault-app/seedvault/wiki/FAQ#why-do-some-apps-not-allow-to-get-backed-up
This is a massive pain to migrate to a new phone without root when even big apps like Firefox prevent us from simply moving relevant files over.

Severity: -- → N/A

(Linking some relevant bugs for visibility)

See Also: → 1440422, 1809963, 1813831

The last time that backups were investigated was in https://github.com/mozilla-mobile/fenix/issues/18373.
The title of that issue is "[Spike] Investigate Android 11 implications for device-to-device backups". The referenced feature was mistakenly attributed to Android 11. The feature was introduced to Android 12 and documented at:

Based on this reading, I would expect Firefox app data to be restored in a device-to-device backup, because the Firefox apps only have allowBackup="false", which is supposedly ignored in a device-to-device transfer scenario. When I tested it with a Google Pixel 3 to 8 (Android 12 -> Android 14), I was surprised to see that no Firefox app data was migrated (in fact, there is barely any app whose app data was meaningfully migrated...).

To migrate Firefox app data across devices, I created a tool and instructions at https://github.com/Rob--W/android-ext-qa/tree/main/firefox-android-backup-restore

(In reply to Rob Wu [:robwu] from comment #3)

To migrate Firefox app data across devices, I created a tool and instructions at https://github.com/Rob--W/android-ext-qa/tree/main/firefox-android-backup-restore

This script works great for backup, thank you!

If all you want to do is to exfiltrate your profile data, and you don't care about restoring the data to the phone with the original file permissions, and you have enough space for a full copy on your phone, here's a slightly simpler alternative: On about:debugging, connect to the device, and scroll all the way to the bottom to the Multiprocess Toolbox, then Inspect. Then paste the following code into the console. It will copy the data directory and then chmod it to make it accessible to the adb shell user.

function runCommand(cmd) {
  const shFile = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsIFile);
  shFile.initWithPath("/bin/sh");
  const shProcess = Cc["@mozilla.org/process/util;1"].createInstance(Ci.nsIProcess);
  shProcess.init(shFile);
  shProcess.run(true, ["-c", cmd], 2);
  return shProcess.exitValue;
}

runCommand("cp -r /data/data/org.mozilla.fenix /storage/emulated/0/Android/data/org.mozilla.fenix/files/");
runCommand("chmod -R a+rX /storage/emulated/0/Android/data/org.mozilla.fenix/files/org.mozilla.fenix");

And then pull the directory using adb pull /storage/emulated/0/Android/data/org.mozilla.fenix/files/org.mozilla.fenix

(In reply to Rob Wu [:robwu] from comment #3)

To migrate Firefox app data across devices, I created a tool and instructions at https://github.com/Rob--W/android-ext-qa/tree/main/firefox-android-backup-restore

Just noting that this android-backup-restore tooling has been very useful in helping to reproduce and find new issues that are specific to larger user profiles. See bug 1995805 and bug 2031843.

You need to log in before you can comment on or make changes to this bug.