* When any Account is modified, MailService gets a content notification and
runs reconciliation in an AsyncTask. Reconciliation ends up calling the
AccountManager, which also runs asynchronously. The net effect is that,
especially during unit tests, where we create/destroy accounts rapidly,
these calls can "back up", ending in a situation in which the worker pool
for AsyncTask is filled, with a resulting RejectedExecutionException
* We fix this by preventing more than one request for reconciliation to
be queued at a time
* Added a unit test that thrashes the notification handler
Bug: 2937628
Change-Id: Iaf25806efb46831f31704604360df091752d9525
Merge commit '73c1645b9052dd52eeca0b4bcf4438e50d0555f9'
* commit '73c1645b9052dd52eeca0b4bcf4438e50d0555f9':
Use original all-day flag when upsyncing exceptions DO NOT MERGE
Merge commit '25cc1ec4de9bfcee0e5b02fa2004435ac0090f93'
* commit '25cc1ec4de9bfcee0e5b02fa2004435ac0090f93':
Fix upsync of exceptions in EAS 2.5 (Exchange 2003) DO NOT MERGE
Merge commit '0f8cd216977887541c977ebffa67925b1f3652ee'
* commit '0f8cd216977887541c977ebffa67925b1f3652ee':
Give email its own version# scheme. DO NOT MERGE
ListView uses the _id column for some operations, including
onSave/RestoreInstanceState, and if the column contains negative values
they don't work as expected. The same assumption seems to be in other places
as well, so let's just avoid using negative IDs.
With this CL we now use two different IDs, one for ListView, which will
never be negative, and the other for us, the actual mailbox ID.
Bug 3049315
Change-Id: I263b4895212b5f8bb80c98acaf5c4eccd0bfef55
Merge commit '214c6c6c8173cf90a3e45615a6896a48dc643e68' into gingerbread-plus-aosp
* commit '214c6c6c8173cf90a3e45615a6896a48dc643e68':
Fix remote wipe with mobile sync server
* 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
Change-Id: Ie9e944bd39f331c2ddc0f0ba303a3d5684f6f033
Merge commit 'efcde27bf74acdd82bb0aad0ad1fd0b767ca5f18' into gingerbread-plus-aosp
* commit 'efcde27bf74acdd82bb0aad0ad1fd0b767ca5f18':
Use original all-day flag when upsyncing exceptions DO NOT MERGE
Merge commit '9c2baaabd2feff633db3ed1b782282667e541927' into gingerbread-plus-aosp
* commit '9c2baaabd2feff633db3ed1b782282667e541927':
Fix upsync of exceptions in EAS 2.5 (Exchange 2003) DO NOT MERGE
* 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
Backport of: I163f156675f65c494a59d5233b2b6e23b3f1d6a0
Change-Id: I5d32dea5c3903147725b8df87a71e961a4d78c60
Merge commit '419a36ca6e8d0c46875e82c1e8be245b45adbb52' into gingerbread-plus-aosp
* commit '419a36ca6e8d0c46875e82c1e8be245b45adbb52':
Give email its own version# scheme. DO NOT MERGE
The problem is that ths method is called in a worker thread, so
there's nothing to prevent it from running just after/at the same
time as clearContent() (which sets -1 to mMessageIdToOpen).
If it does, it passes -1 to restoreMessageWithId() and crashes.
Also removed a half-obsolete comment which is a bit too obvious for its length.
Bug 3077387
Change-Id: I736d696046e6d8964a16c80515544c582aca3943
Show this when there's no messages, and no "Load more messages" footer.
i.e. Only Outbox, Drafts, and exchange mailboxes can show "No messages".
Also removed an obsolete comment.
Bug 2363624
Change-Id: If483d33cfacb186d0fe54b4f4382333a332be84c
* 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
