Merge commit 'b5bf09a56d30885f985950faa1daa18e8899c32e' into froyo-plus-aosp
* commit 'b5bf09a56d30885f985950faa1daa18e8899c32e':
Allow more time for HttpPost watchdog timeout
Merge commit 'f7369ad51f0eb2c231715975de13e4af37c58eb4' into froyo-plus-aosp
* commit 'f7369ad51f0eb2c231715975de13e4af37c58eb4':
Shutdown all connections when sync service is hung
Merge commit 'b915c3c018c8c4ba063514c3bd9ce05d3f08aa93' into froyo-plus-aosp
* commit 'b915c3c018c8c4ba063514c3bd9ce05d3f08aa93':
Skip security check when account id is unknown.
* The current timeout is triggering more often than it should, which
causes delays and inefficiency. Increase it from 10 to 30 seconds.
Bug: 2615293
Change-Id: I54b74cc7ad9f1c8286af49b957584670c071640c
* When a sync thread receives an alarm due to a missed socket timeout
on an HttpPost, we try to abort the HttpPost.
* At times, however, the HttpPost cannot be aborted and the thread
hangs indefinitely.
* In this CL, we try to break this vicious cycle by shutting down our
ClientConnectionManager when this case is detected. This should, in
turn, close all of our socket connections, causing the sync threads
to generate IOExceptions and terminate.
* After appropriate IOException waits, new sync threads should then be
able to run normally.
Bug: 2615293
Change-Id: Idea6c3653cd60822d6260e0c5a7dad790ee25858
Doing the check caused:
IllegalArgumentException: Unknown URI content://com.android.email.provider/account/-1
at com.android.email.provider.EmailProvider.query(EmailProvider.java:1092)
at android.content.ContentProvider$Transport.query(ContentProvider.java:163)
at android.content.ContentResolver.query(ContentResolver.java:245)
at com.android.email.activity.MessageList.isSecurityHold(MessageList.java:1146)
Bug 2635060
Change-Id: I80e7c00ef2dd74ceae24a88daf43a0681124a9d4
* When SyncManager starts up, it reconciles the AccountManager sync settings
with its own
* This works for Contacts, but Calendar has a second setting that needs to be
checked - the sync_events column in the Calendar table (in CalendarProvider2)
* Before turning on Calendar sync, we now check this second setting; if
sync_events is 0, we won't re-enable Calendar sync
Bug: 2619755
Change-Id: Iea6c99dce228d2c111a529a6c9b865ed1577b19e
Merge commit 'd718abd38c12a902b85ba6341c4eda1c778d68b7' into kraken
* commit 'd718abd38c12a902b85ba6341c4eda1c778d68b7':
Increase service call timeout to 45 seconds
Merge commit '17733f228ec131900acd7e5ff883bb0150025c42' into kraken
* commit '17733f228ec131900acd7e5ff883bb0150025c42':
Fix upsync of DAILY rrule with UNTIL
Merge commit 'b62cbc7e7b82739c307b5cb3175bbfff5f549295' into froyo-plus-aosp
* commit 'b62cbc7e7b82739c307b5cb3175bbfff5f549295':
Increase service call timeout to 45 seconds
Merge commit '0f68676828d1f66c7997a0457f1c6536e661658f' into froyo-plus-aosp
* commit '0f68676828d1f66c7997a0457f1c6536e661658f':
Fix upsync of DAILY rrule with UNTIL
* When a sync thread triggers an alarm by failing to return from
an HttpPost beyond the socket timeout, we call abort() on the
HttpPost to force it to stop
* It appears that there are cases in which this is insufficient,
and the thread remains hung in a blocked state
* The result of this failure is to prevent the syncing mailbox from
ever syncing again, and is typically seen by a failure to receive
new mail (as reported in the referenced bug)
* In this CL, we add code to wait for 10 seconds after calling the
abort() method. If the HttpPost is still hung, we interrupt() the
thread, and have SyncManager release the Mailbox, so that another
thread can be started.
Bug: 2615293
Change-Id: I6a48195fc68bb950126006326a5b30448d3bbb63
* Make sure we send UNTIL with FREQ=DAILY as appropriate
* Also to help debug this in the future...
Add logging capability to utilities via SyncManager
Add public log methods so that CalendarUtilities can log properly
Change Log.d's to SyncManager.log in CalendarUtilities
Bug: 2623787
Change-Id: I3d651f00a3f7522e25c8d6e389469770c733953f
* Change "broken pipe" behavior to simply run through the ping loop
again, rather than be treated as a NAT timeout
Bug: 2615293
Change-Id: I67c3200f148a8c2beda58f812c29af8a726a4b9c
Merge commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46' into kraken
* commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46':
Fix upload/download of attendee status
Merge commit 'b11ea045e994d80c49d0a80ca08582554a1c5823' into kraken
* commit 'b11ea045e994d80c49d0a80ca08582554a1c5823':
Add checks for null in SyncManager
Merge commit '2f1ce56fc85e8dc7052dc16f58d00bf19b2a9bee' into froyo-plus-aosp
* commit '2f1ce56fc85e8dc7052dc16f58d00bf19b2a9bee':
Fix upload/download of attendee status
Merge commit '7cb5e144e746b5310d8f9facc24ab992f1a2a67c' into froyo-plus-aosp
* commit '7cb5e144e746b5310d8f9facc24ab992f1a2a67c':
Add checks for null in SyncManager
Merge commit '819de68b01ec9f8d44e4fa1e16bf4900abf90b16' into kraken
* commit '819de68b01ec9f8d44e4fa1e16bf4900abf90b16':
Add additional test for likely NAT timeout
Merge commit 'de3ae17246bc011eff61e18ee1013e146ec53a3d' into froyo-plus-aosp
* commit 'de3ae17246bc011eff61e18ee1013e146ec53a3d':
Add additional test for likely NAT timeout
* When you have 2 or more accounts configured, MessageList gets confused.
* If you are viewing a mailbox from account A, and account B does a
background sync, MessageList gets confused by the reports coming back
from the Controller. It gives up and returns to the Accounts list.
* This change adds a check for the current account and ignores the
MessageList updates if we weren't actually waiting for them.
* To test the positive case for this code (make sure we didn't break it),
verify that the inbox on an IMAP account is displayed properly
immediately after you add it.
Bug: 2619513
Change-Id: Ib31254b4099ba6b7922b06d42e2b7928551e4fb2
* This prevents unnecessary delays in receiving push mail
* At present, there is a likely 5 minute delay on receiving new pushed
mail on the network displaying the behavior we're testing for
Bug: 2615293
Change-Id: Ic42e576fa683790f96434fcbad5ee873d0730f6d
* It turns out that the UI uses selfAttendeeStatus and the attendee's status
from the Attendees table in confusing and undocumented ways
* selfAttendeeStatus is used in the UI, but only in certain cases. Generally speaking,
the Attendees table status is definitive. However, when the user sets his status
from the UI, this data is reflected in the event's selfAttendeeStatus, since for EAS,
the user is always the owner of his calendar
* On downsync, we'll put the user's busy status into the Attendees table
* On upsync, we'll send busy status based on the user's attendee status in the
Attendees table
* We'll use selfAttendeeStatus only to determine whether the user has manually changed
his status via the UI (as before)
Bug: 2615586
Change-Id: I3a82474cfd07cbf5aa595e5214807cb55005cefa
Merge commit 'd764ce7e4442b0027a891582cbdd728487a49f97' into kraken
* commit 'd764ce7e4442b0027a891582cbdd728487a49f97':
Send correct busy status information in upsyncs to EAS
