* 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: I69642cc0097296956029485abb85ac750303c865
We have singletons that store a Context passed to getInstance().
The problem is that when we call them, we casually pass any Context at hand.
If it's an activity (which is often the case), it'll never be GCed.
This CL make them store the application context insteaed.
Change-Id: I1abcc2c08d3f8201416d6c14720f041693823b4e
- A few new tests in ImapStoreUnitTests.
- Added TODOs to ImapStoreUnitTests (for mainly NO response handling)
- Renamed ImapStore.releaseConnection to poolConnection.
- Fixed a bug in getConnection where it'd return a closed connection.
- Now getConnection() hanles BYE response for NOOP correctly and treat the
connection as closed.
Change-Id: I48e5b89049338f7d4f1ac77cd7ac7243945a9575
* 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: I85981b85b71c4e7d53e69da2520543e8ef04c889
* 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
- Also, fixed a potential crash in getMessages().
It could happen when a client is gettign a message list while
another client is removing messages.
Change-Id: I04b1de6bc384cffb7a5286bcec0a349a3d62a623
Make the date parser accept invalid dates like
"Thu, 10 Dec 09 15:08:08 GMT-0700" which was observed in an email from eBay.
Per RFC, timezone must be either obs-zone (e.g. "GMT") or +/- with 4 digits.
The GMT+/-digits format is not permitted.
Bug 2367124
Change-Id: I59968274160aeadea70223208b463ee692660056
Follow up to I3bf7d340. Make sure temp directory is set before running tests.
Turned out Application.onCreate doesn't seem to be guaranteed to be run
before unit tests.
Without this, some tests may fail saying: "TempDirectory not set.
Application hasn't started??", if onCreate runs too late.
Change-Id: Ic5aee939a2c21f9579a643d0729dd0e9ba81022e
* Move all thread-related startup code into run()
* Move all thread-related shutdown code into new method shutdown()
* Add appropriate synchronization during startup/shutdown
* Add thread names to worker threads
Bug; 2645835
Change-Id: Idbd35892cea3de5fbd365102a62103b2f0bdf6c9
Main motivation: not to make the new IMAP parser too complecated.
- Removed messageRetrieved.
Motivation:
- It's not easy to call messageRetrieved() at the proper timing
from the new IMAP parser, and this method wasn't used anyway.
- Renamed messageFinished to messageRetrieved.
And removed the "number" and "ofTotal" arguments.
Motivation:
- They weren't used. Also there was inconsistency about
what to pass as "numebr". (i.e. 0-based or 1-based?) There was
even a bug that caused passing a wrong number.
Change-Id: If92dbfe681b78a0eea8125188ede63a8f00dcf49
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
