User:Anaaktgeboren/NativeSync

Android Sync behavior with multiple Firefox versions installed

User Support

• Mozilla only supports one installation of Firefox for Android at a time, and a single Firefox Sync account. Attempting to set up Firefox Sync with multiple Firefox installations (e.g., Firefox and Firefox Beta) may result in a failure to set up an account. Forcing multiple Firefox versions to sync will fail.
• In order to resolve Firefox Sync setup and syncing failures, please choose one Firefox installation to keep, and uninstall the others by going to Settings → Apps → All, selecting each unwanted Firefox installation, and clicking "Uninstall."
• You can have both a "Native" Firefox and a "XUL" Firefox installed at the same time without problems.

Technical Examination

Firefox for Android includes an Android-native implementation of Firefox Sync: a background data synchronization component termed "Android Sync".

We currently only support a single Firefox installation per device if Sync is used. This is due to a number of technical constraints, best summed up as "Android expects only a single application to control each account, but we ship the code that manages the account with each version of Firefox".

We will be addressing these constraints in future releases.

User Experience

• If two versions of Firefox are installed, the behavior of the system during Sync setup is undefined. Setup might complete if the user starts setup from the 'correct' version (which appears to be arbitrary). Installing a second version of Firefox after setting up Sync is likely to be safe, but it will not sync. Switching between versions of Firefox, but keeping only one permanently installed, is likely to be successful.
• Precise behavior seems to depend on order of installation and Sync setup, as well as Android version.

Developer Overview

Android Sync exposes an Android SyncAdapter and account setup activities, and Firefox uses Android Sync to sync history, bookmarks, passwords, forms, tabs, etc.

Firefox Sync account credentials are only accessible to Sync and Firefox: the authenticator service is not exported. Android Sync functionality is bundled with the Firefox browser in a single APK.

Android associates an account type (e.g., org.mozilla.firefox_sync) with an account authenticator, and implicitly with the system uid of the authenticator.

In the following sections, we detail the behavior of multiple Firefox installations.

Setup

If you have a Firefox version (e.g., Nightly) installed, and you install a second, different version of Firefox (e.g., Aurora), then there will be two applications which each claim to 'own' the Firefox Sync account type. Attempting to set up a Firefox Sync account for the Aurora installation will fail if Android has decided that Nightly owns the account type, or vice versa; the Nightly Sync setup activity doesn't share Aurora's Android uid, and thus isn't permitted to create the account. The only way to get Sync setup working with the new installation is to uninstall the previous version(s) of Firefox.

Syncing

In the Firefox Sync account settings, under Settings → Accounts → (your Firefox Account), all Firefox installations will show up as sync-able options. Only the Firefox version that provided the Sync setup activity will be checked. Attempting to sync any of the other Firefox versions will fail, because only the original Firefox's Sync AccountAuthenticator will be permitted to access necessary metadata. (If this were to succeed, Sync would not behave correctly when tracking changes in each profile.) In order to sync an account with a particular Firefox installation, uninstall all other Firefox versions. In the Firefox Account settings, under Settings → Accounts → (your Firefox Account), make sure the Firefox version is checked (it should be the only option).

Possible improvements

We would like to support simultaneous syncing of multiple versions of Firefox, and multiple profiles, in a future release. Some avenues to explore are:

• Providing distinct account types for each version of Firefox. (That is, you might have a "Firefox Sync", a "Firefox Sync for Aurora", and a "Firefox Sync for Nightly" account.)
  • Undesirable because it limits the ability to switch between channels, besides presenting a confusing user experience.
  • The only approach that's 100% likely to work.

• Exporting the Sync authenticator, accessing it by reference, and allowing Android to determine which authenticator code runs.
  • Risk here in allowing significant version mismatch: you might get Firefox 14's setup or authentication code running when testing Firefox 16. Account types will need to change as significant differences are implemented.
  • Requires code signing protections (which hampers testing of custom builds against release builds) to avoid access to credentials by other Android applications.
  • Might not work at all if Android does not permit more than one application to export an authenticator in this way.

• Shipping Sync as a separate system component.
  • Introduces packaging, deployment, and Fennec integration difficulties.

Regardless, we will also need to address:

• UX issues — how to configure an account that will sync to three different Firefox profiles, or how to sanely present multiple Firefox applications in different accounts.
• Internal data storage — correct storage of prefs and timestamps in a per-profile, per-application, per-account way.
• Consistency — preventing an application's profile from syncing to more than one Sync account.

Engineering Notes

Triage

• Sync Queries
  • beta blockers
  • soft blockers
  • release blockers

Bugzilla descriptions

General whiteboard flags

• [not code] - this bug deals with something that is not actionable in code, such as documentation
• [not started] - work has not started
• [work started] - coding has begun
• [decision needed] - work cannot proceed until a decision is made

Sync-specific whiteboard flags

Since the Sync team works in GitHub, Bugzilla does not reflect the review state of in-progress work. These whiteboard flags indicate when work has reached the review stage. Usually a pull request URL is added to the bug as work gets underway.

• [needs review :<nick>] - code is waiting for review from <nick>
• [in testing] - prior to landing, our code is QAed, this may be different from other groups who land and then QA

Landing state

• Work lands on mozilla-inbound. Per inbound rules, we don't use a whiteboard flag for this; instead, 'target-milestone' is set to the next release (currently 15). Also ensure that the bug is ASSIGNED.
• When mozilla-inbound is merged to mozilla-central, the bug is RESOLVED FIXED.
• When QA has verified the fix, the bug is VERIFIED FIXED.

That is: work proceeds from [not started] → [work started] → [needs review] → TM=15 → TM=15 + RESOLVED → TM=15 + VERIFIED.

When work is uplifted to Aurora, its 'status-firefox14' flag is set to 'fixed'.

Having the resolution, target-milestone, and status-firefoxN flags visible in Bugzilla search results will give an at-a-glance view of the landing state of a bug.

Testing

• android sync jenkins instance
• waiting on a tegra board hookup for the services build machine (located in sf between :ally's & :gps' desk)
  • :mconnor is looking into it

Cases that need testing for blank server and corrupted server

All tested with Fennec nightly:

20120507030511
http://hg.mozilla.org/mozilla-central/rev/448f554f6acb

• what does Native sync do when finding a blank server:
  • with no meta/global?
    • first sync log File:~/Mozilla/nomg.1.log
    • cleared account data via Account Portal
    • sync with no meta/global may hang? File:~/Mozilla/nomg.2.log
    • and again: File:~/Mozilla/nomg.3.log
    • definitely no meta/global uploaded.
• what does Native sync do when finding a corrupt/changed server:
  • with a changed meta/global:
    • with a different syncID?
    • with a different storageVersion?
    • with a broken engines record?
  • with a valid meta/global, but:
    • without crypto/keys
    • with wrong crypto/keys
• does Native sync have large race windows:
  • when uploading meta/global?
  • when uploading crypto/keys?