710407 - Define and document Android Sync behavior if multiple Firefox versions (e.g., Nightly, Aurora, and Beta) are installed

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Android Sync, defect, P1)

Description

[Allison Naaktgeboren :ally]

Sync's behavior on android is undefined if more than one version of firefox is installed. What, if any, should the behavior be, and is the desired behavior even technically feasible?

Comment 1

[Richard Newman [:rnewman]]

Will require investigation of in-apk private content providers, what happens if those are exported, how Accounts are tied to SyncAdapters, whether multiple SyncAdapters can exist with the same package, etc. etc.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

bug 710575 should resolve this functionally. Not sure what you need documentation-wise.

Comment 3

[Richard Newman [:rnewman]]

I've done some investigation / preliminary work on this.

Having Sync target its companion version of Fennec is reasonably straightforward: preprocess our authority URLs to match Fennec's. This is already done (though Bug 710575 was incomplete; see Bug 711627).

Having multiple Sync installations is less easily achieved. Sync by its nature tightly integrates with Android's service infrastructure, exposing a SyncAdapter as well as its associated account setup activities. Those services are all named, and those names are required to be part of the package structure of the application. Changing the name means changing the packages of the classes that implement the service. The account types, too, must be globally unique.

Getting Sync to a point where it's preprocessable in this way isn't _impossible_, merely unpleasant (it either involves lots and lots of sed, or breaking the ability to edit this code in a Java environment, which is the only thing that makes Java bearable) and very time consuming -- I stopped and took a step back when I started having to process whole subtrees (activities, services, the service descriptor, the manifest…), and that's even ignoring Java package qualification nonsense.

I'm not currently willing to abandon the ability to get work done in Eclipse, or spend the time to build a generic preprocessing task that preserves Java-ness. Working against the grain in this way to achieve a non-user-facing feature is near the bottom of my list of things to do.

Consequently, our original constraint -- only one installation of Sync is supported per device -- still stands, and we'll have to bounce this feature creep. If bundling Sync with Fennec carries this constraint over to Fennec, then I'm afraid that's the situation for the near future. An easy workaround would be to omit the Sync service descriptor elements from whichever Fennec versions don't need Sync. I seem to be able to install standalone Sync alongside Fennec+Sync, but I have no idea what will actually happen if you try to use them both, so I suggest avoiding this.


tl;dr: Android doesn't make it easy for you to install multiple versions of the same service, as it ties code structure to advertised features. For the time being, we're not going to support multiple instances of Sync on one device.

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #3)
> I'm not currently willing to abandon the ability to get work done in
> Eclipse, or spend the time to build a generic preprocessing task that
> preserves Java-ness. Working against the grain in this way to achieve a
> non-user-facing feature is near the bottom of my list of things to do.

First, I disagree that this is not a user facing feature. When we release we'll have two products with sync enabled in the market (Firefox and Firefox Beta).

To minimize the pain of preprocessing java files you should look at what we do with GeckoApp.java and App.java.in. Basically all the code you'll ever actually edit is in GeckoApp.java. App.java.in is a subclass of GeckoApp and is preprocessed to get the package names right. This sort of thing should be pretty strait forward for sync to do as well.

Comment 6

[Richard Newman [:rnewman]]

(In reply to Brad Lassey [:blassey] from comment #5)

> First, I disagree that this is not a user facing feature. When we release
> we'll have two products with sync enabled in the market (Firefox and Firefox
> Beta).

The reason why I over-simplified to "non-user-facing" is that not many people should be trying this: only testers. I don't feel that it's worth our time to try to jump from one bad experience to another for the fraction of users that are going to routinely try to use Sync accounts with two different versions of Firefox, just as we don't yet allow you to use two different Sync accounts on the same device.

It's not possible to have only one entry appear in Accounts if two versions of Firefox are installed. Awful UX, but utterly unavoidable unless we have users install a separate Firefox Sync .apk and unbundle Sync from Fennec. Android accounts are meant to be shared between products, and the combination of Fennec and Sync are unable to behave in that expected way.

There's no good UX possible here so long as every version of Fennec ships claiming to own your Firefox Sync account: either they collide badly, or there are "Firefox Sync for Aurora" and "Firefox Sync" accounts hanging around. Either one is surprising, and the latter involves some ill-defined quantity of work.

Sync is -- for now, anyway -- for one Sync account for one Firefox. Anything else is ambiguous. We can consider doing some work to address this when we have some clear win that we can work towards, but until then it would be misusing our limited resources. I'd much rather be spending the time meeting user expectations for reliability and feature completeness.


> To minimize the pain of preprocessing java files you should look at what we
> do with GeckoApp.java and App.java.in. Basically all the code you'll ever
> actually edit is in GeckoApp.java. App.java.in is a subclass of GeckoApp and
> is preprocessed to get the package names right. This sort of thing should be
> pretty strait forward for sync to do as well.

Neat! Thanks for the tip!

Comment 7

[Richard Newman [:rnewman]]

With current Fennec and Nightly builds, enough bits and pieces line up for Android to recognize that the browser content provider (bookmarks and history) for both versions, and the Sync service provider, each connect. Android thus shows *one* account type, with a checkbox for each content provider -- just as you get a checkbox for "Sync mail", "Sync calendar" in your Google account. You see "Sync Fennec", "Sync Nightly". (Good spot, Doug!)

No way of choosing which Sync code runs, I suspect, and I doubt that this is correct -- at the very least, Sync doesn't correlate the two when it tracks changes -- but it might be a way forward in the future if this collision is reliable.

Hilarious.

This will probably break completely when the passwords CP lands.

Comment 8

[Richard Newman [:rnewman]]

My brain was stewing during the night after addressing Bug 732751.

Here's a possible set of improvements that will render things *slightly* less broken.

0. Add logging to SyncAdapter and SyncAuthenticator that will log the product name. That'll be interesting.

1. Fennec's "set up Sync" action needs to ask the AccountManager to create an account, rather than launching Sync's activity directly. That will ensure that AccountManager agrees with itself, and eliminate the "uid mismatch" class of bugs, at the cost of running setup code that might have shipped with a different version of Firefox.

(Yes, you might get Fx12's setup code when you're running Fx15. That's a consequence of shipping the authenticator with each product. We either fail on creation, or we get stale code.)

http://developer.android.com/reference/android/accounts/AccountManager.html#addAccount%28java.lang.String,%20java.lang.String,%20java.lang.String[],%20android.os.Bundle,%20android.app.Activity,%20android.accounts.AccountManagerCallback%3Candroid.os.Bundle%3E,%20android.os.Handler%29

2. We can consider having a separate account type for pre-Aurora builds, which should address most of the "I'm running Nightly and Aurora" users without impacting UX too much. Of course, Fennec will need to use the correct account string when launching setup.

I will investigate some of these when I have time.

Comment 9

[Peter Retzer (:pretzer)]

Can we at least have documentation somewhere (e.g. SUMO) what this actually means for users with two versions, before we ship? 
In the future there might be many user having native release and native beta simultaneously on their phones, given that both are on the market. There should be a clearer story than just "behavior is undefined".

Comment 10

[Richard Newman [:rnewman]]

The definition of beta blocking here is "we need to have an idea of what we're going to do, and ideally some docs".

That is, we want to know before beta if we're painting ourselves into a corner.

I believe product's stated direction is "not supported", but of course we would like to make life easier for people testing.

I'm feeling vaguely positive about our options, here: options 1 and 2 in Comment 8 are both sustainable long-term (with the exception of a switchover between incompatible release types). Bad UX from either option isn't likely to be too impactful, because the number of users with multiple Sync accounts on the same device should be small.

I would like UX input here. madhava, ibarlow? (I am happy to discuss the issue over video if that would help.)

Comment 11

[JP Rosevear [:jpr]]

Ally is going to set up a meeting to get this to done.

Comment 12

[Allison Naaktgeboren :ally]

Ian, madhava, rnewman requests ux input in comment 10. Do you have any strong opinions on this?

Comment 13

[Ian Barlow (:ibarlow)]

Hi Ally, I think to rnewman's point, a meeting would be helpful to help us better understand all the variables. Would you mind setting one up? 

Thanks!

Comment 14

[Allison Naaktgeboren :ally]

rnewman & I did not think this was worth a meeting if UX/UR did not have any strong opinions about the implementation paths.

It sounds like you might though? If so, I will schedule a meeting.

Comment 15

[Ian Barlow (:ibarlow)]

Hi all, just read the comments again and wanted to offer my opinion here, instead of having a big meeting about it :)

It strikes me that sync behaviour should behave very similarly to profile behaviour, in that from a user's perspective, they only have one and it works everywhere. I worry about getting into the territory of managing multiple sync accounts for different versions of firefox, because it feels like it adds complexity to our sync service instead of simplifying it. 

Happy to discuss this further if needed, but in general the more we can do to simplify the appearance of Sync to our users, the better.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

We need a wiki page or something that is the "source of truth" for the current definition. I am having a hard time trying to gleam the definition from this bug.

Comment 17

[Richard Newman [:rnewman]]

(In reply to Mark Finkle (:mfinkle) from comment #16)
> We need a wiki page or something that is the "source of truth" for the
> current definition. I am having a hard time trying to gleam the definition
> from this bug.

Yeah, writing that page is the goal of this bug :D

Comment 18

[Allison Naaktgeboren :ally]

mobile triage: we shall have such a page by april 23rd, aurora uplift

Comment 19

[Allison Naaktgeboren :ally]

doc in progress, testing of different combinations in progress

Comment 20

[Allison Naaktgeboren :ally]

draft in initial review

Comment 21

[Tony Chung [:tchung]]

(In reply to :Ally Naaktgeboren from comment #20)
> draft in initial review

please loop in QA to help with review.  we can help document some of the angles seen.

Comment 22

[Allison Naaktgeboren :ally]

https://wiki.mozilla.org/User:Anaaktgeboren/NativeSync#Android_Sync_behavior_with_multiple_Firefox_versions_installed

Comment 23

[Allison Naaktgeboren :ally]

doc has been reviewed

Comment 24

[JP Rosevear [:jpr]]

Not code, so implicitly fixed for 14.

Comment 25

[Peter Retzer (:pretzer)]

how will this be communicated to users?