* It appears as if our running multiple sync threads can confuse the
mobile sync server during a remote wipe (the server expects the next
client response to be an acknowledgment, whereas it might well be
a command or response from a different thread)
* To avoid this, we first put the account on security hold and then
shut down all other sync threads for the account
* After this, we send the acknowledgment and the remote wipe proceeds
normally.
* NOTE: It's possible that, due to the vagaries of multithreaded
operation, one of the other syncing threads could still send a non-
acknowledgment response to the server before our provisioning thread
gets a chance to send its acknowledgment. However, since the other
syncing threads will terminate (and not restart, because of the hold),
the provision/remote wipe/ack sequence will work on the subsequent
attempt
Bug: 2844888
Backport From: Ib4ffbbc67b681e69176b6c1d5515fa80c7d1e121
Backport From: Ie9e944bd39f331c2ddc0f0ba303a3d5684f6f033
Change-Id: Ie57f13a5ca2149961a48b99afaebb812f1cbc88e
* Remove three unneeded DB lookups
* Eliminate race condition that could cause NPE
* Remove protocol field from report, it wasn't needed (we already
set the sync interval to -1 which has the same effect.)
Note, the problems were introduced unintentionally, due to the merged
result of three different CL's:
I168b3db49bf422b33d05f25cfff1c7be15150c2b
I74a3dae21d9ec16f9903bdf2a1c28092ae89cc50
I53e935f8bf08e0bda6e2cd483229a6377ed39d74
Bug: 3139451
Change-Id: Iadbed267f88808aeace0a2f011e4acf79074af70
* It's possible that endDownload will be called for a request
that has been dequeued.
* Harden endDownload against this eventuality, so that we clean
up properly without throwing exceptions
Bug: 3142618
Change-Id: If61136ed1ea972248fc5f9388beaaf84754f9931
* An unexpected (runtime) exception during a callback left the
broadcast unfinished, leading to a fatal exception
* Ensure that we always call finishBroadcast()
* Catch RuntimeException in a broadcast call, so that other calls
can be executed
* Addresses one of two issues in the referenced bug
Bug: 3142618
Change-Id: I77166bf927560681a2b189906cd687a6e3585223
We'll have both the action bar and the title bar, but we need the action bar
to access menu commands. This is necessary to make sure phone UI hasn't
been broken.
Change-Id: I5f6f72934d0346cbb01bdd98d31ba19ee0458aef
* For now, clicking on the notification takes the user to the
Welcome activity, as we don't have final flows for the new
account setup UI
* Need comment on strings; the problem is that notification
text must be rather short if we're to use the standard
notification display. It looks like newer UI will allow
3 lines instead of 2, however.
* Tested w/ IMAP, POP3, EAS, and SMTP
Bug: 2322253
Change-Id: I7ed6fa5599179870cbcdb14af062e956eff37ec5
* EasSyncService was using the callback for all syncs, including
those running in the background. We really only want to report
back when syncs initiated by Controller fail...
Bug: 2239661
Change-Id: I7c4aceb74fe94ca38f5bdbbabe5dda62ccac60ec
Merge commit '641ef663f3b141c2ca99fa67db20fcb3608b71e7' into gingerbread-plus-aosp
* commit '641ef663f3b141c2ca99fa67db20fcb3608b71e7':
Import revised translations. DO NOT MERGE
* EAS 12.0/12.1 don't mind these, but EAS 2.5 objects in some cases
(title and prefix, certainly) and the upsync fails
* The error case occurs because the ContentValues provided by
ContactsProvider actually has a value; the value, however, is an
empty string
* Prevent this by checking for empty values before serializing
Bug: 2607778
Change-Id: I853ce711024a414f53861720000cc87a7349d660
I should have been used the one without default in the main code,
which uses the other one (with a default), so both can safely be used
in tests.
Bug 3107191
Change-Id: I2011d96f6824a1a6e99e81f5c8e60c966a444d92
