* 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
Change-Id: Ib4ffbbc67b681e69176b6c1d5515fa80c7d1e121
* Apparently, Exchange 2003 doesn't like to see Visibility set in
Exceptions
* Apparently, Exchange 2003 likes to see Exception Deleted and
ExceptionStartTime prior to other data
* The word "apparently" is used above to indicate that these
findings are not part of any specification, but have been
determined empirically
Bug: 2775885
Change-Id: I163f156675f65c494a59d5233b2b6e23b3f1d6a0
Current implementation ignores callbacks coming from
AccountManager, which should be called everytime
when this Activity finishes its job.
Bug: 3069222
Change-Id: Iea03cf94bdfe8da184e415bf7e759ddeb46ecdd9
Refresh mailbox list when changing the account, if it's been more than
5 minutes since the last refresh.
Change-Id: I5b1400bb881197e117b8863f850c368c2d1ccbc6
I was assuming MailService.resetNewMessageCount cleared notification,
but it didn't.
Doing it in Activity.onResume is clearly wrong because we don't always
have an account ID there. If we don't, we're passing -1, which clears
all notifications for all accounts.
We're now calling resetNewMessageCount() in MessageListFragment,
when we refresh the list, so we can remove it from onResume() for the Phone
UI as well.
Bug 3074056
Change-Id: Ib0bb2fbb0309a0784fb3a525927102f423e930df
Merge commit 'ba95e58afd450b747eba87c614db98cc221ed804' into gingerbread-plus-aosp
* commit 'ba95e58afd450b747eba87c614db98cc221ed804':
New downscaled menu assets
The method to start ReloadMessageTask() when detecting content
changed events is delay-called, so need to make sure the fragment
is still in the valid state.
Bug 3069896
Change-Id: I1991d902e8044b4f8ca3ffd7d3e2e66005f1e960
Added "tabs" to the message view according to the latset mock.
This removes the necessity of putting a WebView inside a ScrollView,
which caused the infinitely-growing email bug (issue 6882).
Right now the tabs are actually just Buttons. Complete visual refresh
should follow it.
http://code.google.com/p/android/issues/detail?id=6882
Bug 2349275
Change-Id: I897a3a32e0dd7a90d637ac5ea1d47e5e65a1eabe
Merge commit '79b05696876aadada8cb3f21f89f36b7ae72121d'
* commit '79b05696876aadada8cb3f21f89f36b7ae72121d':
Reorganize startup/shutdown code in SyncManager DO NOT MERGE
Now MessageViewFragment detects changes made to the current message,
and update the UI.
(Although it doesn't really know if the message is really changed, or just
something else was changed in the DB. It updates the header regardless.)
Change-Id: I35627c7aff129723b83605fc84521da907078571
Moved the buttons to the header. All other buttons below the message view
go away, so I just hid the old buttons.
Also now we stop trying to hide these buttons when entering contextual mode,
which fixes bug 3044284: Message view buttons get disabled when closing
quick contact
Assets were temporarily copied from gmail.
Change-Id: Ib178c6221dfab02832a10d0c0441044e4969fb70
Merge commit 'd7876681a85a4cc799feec775bdfe7927f983464' into gingerbread-plus-aosp
* commit 'd7876681a85a4cc799feec775bdfe7927f983464':
Reorganize startup/shutdown code in SyncManager DO NOT MERGE
