958900 - Schedule a periodic sync for new FxAccountSyncAdapter

Status: RESOLVED FIXED

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

Description

[Nick Alexander :nalexander [he/him]]

Related to Bug 726055 but not tracked there yet.

We should add a periodic sync, contingent upon your Firefox Account state:

* if your account is invalid or needs updated credentials, never;
* if your account is waiting to be verified, aggressively (we want to drive conversions, and react to verification ASAP);
* if your account is syncing and you're the only device, infrequently;
* if your account is syncing and you're part of a a constellation of devices, frequently;
* if your account is in an error state, very infrequently.

http://developer.android.com/reference/android/content/ContentResolver.html#addPeriodicSync%28android.accounts.Account,%20java.lang.String,%20android.os.Bundle,%20long%29

Comment 1

[Richard Newman [:rnewman]]

Intuition suggests that the periodic syncing interface isn't designed for very short intervals, as we'd want for the verification waiting period, so perhaps we'd be better off with a small alarm-driven service for that? Would allow for more persistent state, too.

Also need to make sure that an interruption in verification -- e.g., a user who wanders off, doesn't have that email account set up on their phone yet, etc. -- doesn't result in killing their battery. Needs an exponential backoff, I imagine, and adjusting to match the network state.

And a final note: for the routine state of affairs (3 and 4), we need to make sure that the internal rate limiting is adjusted to match (or replaced by an Android-native equivalent). No sense having the system trigger syncs more frequently than we're set up to allow.

Comment 2

[Richard Newman [:rnewman]]

Attachment: First steps.

Early feedback, please.

Comment 3

[Richard Newman [:rnewman]]

This pull req covers tracking and checking backoff for an abstract "scheduling" concept, the token server, and the current storage server. It wires in a BackoffHandler into the normal spot to handle GlobalSession backoff notices, and also tracks token failures.

This also schedules periodic syncs to match the number of clients and backoff notices.

Needs tests (and testing), but it's getting there.

Comment 4

[Nick Alexander :nalexander [he/him]]

rnewman: this is reviewed but not landed, right?

Comment 5

[Richard Newman [:rnewman]]

(In reply to Nick Alexander :nalexander from comment #4)
> rnewman: this is reviewed but not landed, right?

Correct. James and I are planning a QA session this morning to exercise all of the backoff cases.

I put together a test plan:

https://etherpad.mozilla.org/fxa-sync-backoff-test-plan

and addressed all of the success cases already, so we're just in error-handling land now.

Comment 6

[Richard Newman [:rnewman]]

Attachment: Final patch.

Carrying forward review, even though I fixed some things after today's marathon QA session.

Comment 7

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/fx-team/rev/dd12b3213d88

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dd12b3213d88

Comment 9

[Richard Newman [:rnewman]]

Comment on attachment 8376016 [details] [diff] [review]
Final patch.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  FxA Sync.

User impact if declined: 
Testing completed (on m-c, etc.): 
  m-c and QAed.

Risk to taking this patch (and alternatives if risky): 
String or IDL/UUID changes made by this patch:

Comment 10

[Richard Newman [:rnewman]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/554e17cd4f4b