* In bug 2703075, all-day events from time zones at GMT or later
appear a day early; this is because the time was calculated from
the GMT date/time of the event rather than the local date/time of
the event; this CL correctly changes this to use local date/time
* In bug 2707966, device-edited all-day events disappear in Outlook
and OWA after upsync; this is due to the fact that we store all-day
events in UTC on device, whereas we need to upload all-day events
using the original (local) time zone. In this CL, we save away
the original time zone and use it on upsync
* In our decoding of Exchange time zone information, we default to
local time when we can't find a time zone that matches the bias
and DST information; we should really default to a time zone with
the same bias, if one exists; we do that in this CL.
* Add/modify unit tests
Bug: 2703075
Change-Id: Id80c481ecc0eae980b2e91dae7f105f924cfca28
Merge commit '5c0f3b332f6104d6526d546a470cf7eb9978de47' into kraken
* commit '5c0f3b332f6104d6526d546a470cf7eb9978de47':
Fix problem w/ sync of large calendars (never syncs)
Merge commit '6bd7a167249727f4b7d4d4cfe713be421f400e51' into froyo-plus-aosp
* commit '6bd7a167249727f4b7d4d4cfe713be421f400e51':
Fix problem w/ sync of large calendars (never syncs)
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: Ib20ea56fb380ee8c9a01b139f7fa98b7ff505e7a
* Microsoft has documented cases in which the server can continue to
send MoreAvailable=true even when no new data is received. This
can cause looping behavior, which we stop when we recognize it.
* This workaround, however, can prevent the situation from resolving
itself, and lead to delayed sync (up to a few hours has been noticed)
* In this limited CL, we allow the sync to loop up to a maximum number
of times before stopping it forcibly.
Bug: 2685984
Change-Id: I2913b7e3438f6180c3c440508fab892176a06540
Merge commit 'c7931b07e605bca3b59f295877fea7f163001a66' into kraken
* commit 'c7931b07e605bca3b59f295877fea7f163001a66':
Test for NPE in EasSyncService during alarm() call
Merge commit 'e0ebcd8e6c04fc3d39844722bce74abe540bfe3c' into froyo-plus-aosp
* commit 'e0ebcd8e6c04fc3d39844722bce74abe540bfe3c':
Test for NPE in EasSyncService during alarm() call
Merge commit '1a9ea35b93f29c589d3e31d70567f076b2bbb26b' into kraken
* commit '1a9ea35b93f29c589d3e31d70567f076b2bbb26b':
Try autodiscover with bare name if we get 401 with address
Merge commit '3778b3ed7ee505c00fa7cd3b1af37cbe54de244a' into froyo-plus-aosp
* commit '3778b3ed7ee505c00fa7cd3b1af37cbe54de244a':
Try autodiscover with bare name if we get 401 with address
* Some autodiscover servers appear to require the bare user name
for authentication rather than the user's email address. This
is apparently common for complex organizations maintaining a
group of email domains
* If we get a 401 when trying to connect to an autodiscover server
using the email address, we try again using just the bare name
Bug: 2682833
Change-Id: Ia07ca336e189069d4f3539e2245b3d53c82e3324
Merge commit 'd40977d14a355fc4d610f4fd8bcbb6196f5cfc96' into kraken
* commit 'd40977d14a355fc4d610f4fd8bcbb6196f5cfc96':
Server sending unsupported policies will cause NPE
Merge commit '8100a2dc5510d0449921895e2af8472d3666fda3' into froyo-plus-aosp
* commit '8100a2dc5510d0449921895e2af8472d3666fda3':
Server sending unsupported policies will cause NPE
Merge commit '3a07d70b69a579ef839faba3b85171b983bec312' into kraken
* commit '3a07d70b69a579ef839faba3b85171b983bec312':
Fix NPE resulting from attendees-only update from server
Merge commit 'a2496548c6ed07cb6cb3820c9922a0e96ca2b8a4' into kraken
* commit 'a2496548c6ed07cb6cb3820c9922a0e96ca2b8a4':
Start sync ASAP when calendar is re-enabled
Merge commit 'd1e00e8aa69ccad3de61ed638b70bf5a9e5bd937' into froyo-plus-aosp
* commit 'd1e00e8aa69ccad3de61ed638b70bf5a9e5bd937':
Fix NPE resulting from attendees-only update from server
Merge commit 'c901810f84754c80aa3988b26f5ff620373f9a46' into froyo-plus-aosp
* commit 'c901810f84754c80aa3988b26f5ff620373f9a46':
Start sync ASAP when calendar is re-enabled
* Code for updating attendees in CalendarProvider2 wasn't taking
an attendees-only update into consideration
* Fix code to allow for this, including proper updates for our
selfAttendeeStatus and attendees ExtendedProperty values
Bug: 2668682
Change-Id: I8c7deb971cd0b6846c09ee3cd603f6fc762a9407
* It turns out that, in addition to other requirements of the
CalendarProvider, there is another - that the ORIGINAL_INSTANCE_TIME
also be set with hour, minute, and second as zero (in UTC)
* Change setTimes() to properly modify ORIGINAL_INSTANCE_TIME
* Also, there was a regression due to an incorrect validity test
for events; this regression caused all exception downsyncs to fail
* Changed isValidEventValues() to be correct for both exceptions
and original events
* Update tests for setTimes and isValidEventValues()
* This CL also fixes 2658988
Bug: 2664229
Change-Id: I9c8aea08e606ff58e5be37ca81a2d86a181c46f6
Merge commit '630758ef898964814072467454bea615d31fc4ff' into kraken
* commit '630758ef898964814072467454bea615d31fc4ff':
Shut down Email process when sync is totally blocked
Merge commit '3558e5f2277fe953c612b42576afe1fb8fae99c8' into froyo-plus-aosp
* commit '3558e5f2277fe953c612b42576afe1fb8fae99c8':
Shut down Email process when sync is totally blocked
* When sync threads get blocked by SSL/Socket code, we detect this
and shutdown the ClientConnectionManager, hoping this will solve
the problem.
* Apparently, this doesn't always work. The result is that syncs
are frozen until the device is rebooted (certainly) or until the
Email process is stopped and restarted (hopefully)
* This CL kills the Email process after an unsuccessful attempt to
clear blocked threads using ClientConnectionManager.shutdown()
Bug: 2615293
Change-Id: I8445b278817e508a855adeb88d6b2f969d28858b
Merge commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6' into kraken
* commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6':
Add checks for Event validity before commit
Merge commit '8f255ddeee95f1f14aa77b2f51e3c69225fdaf6a' into froyo-plus-aosp
* commit '8f255ddeee95f1f14aa77b2f51e3c69225fdaf6a':
Add checks for Event validity before commit
* Enforce CalendarProvider2's requirements for valid Events
* Add unit tests for the new code
* Backport of change I42ad7acb from master
Bug: 2658149
Change-Id: I8151d035247a7dbb1fda3eae163b24ccfe055299
Merge commit 'a094cc259da268ad6f78f50afe5cbbf674418b86' into kraken
* commit 'a094cc259da268ad6f78f50afe5cbbf674418b86':
Collectly preserve the service start-id.
