* When settings are changed, we loop through the sync error map,
clearing mailboxes in the changed account that are in an error
state.
* It's possible that there are mailboxes referenced in the map that
no longer exist. When trying to retrieve them from the provider,
null is returned, but we're not checking for this case, and an
NPE results.
* The fix is simply to check for null, and clear the error map for
the mailboxId that references a deleted mailbox
Change-Id: I8c1c847090026fa1c53b09bbe6b12d864bce4df1
Merge commit '743b143d0e06c7d3b8d8a28e9da3959649a2977c' into eclair-mr2
* commit '743b143d0e06c7d3b8d8a28e9da3959649a2977c':
Import revised translations. DO NOT MERGE
Merge commit 'bf67508d167339f303f2b9985516af3aa01aee51' into eclair-mr2
* commit 'bf67508d167339f303f2b9985516af3aa01aee51':
Import revised translations. DO NOT MERGE
* Currently, we validate EAS accounts using a command that will
succeed even if we do not support required security policies.
* This causes a confusing "invalid username or password" error
when trying to sync with a validated account in the case that
there are, in fact, required policies
* The fix is to send a sync command after validating the user name
and password; a 403 error indicates the requirement for
security policies.
* When we see the 403 error, we put up a message that is appropriate
to the situation.
Change-Id: I74e132cb81f021cbb697cc9ee146405bf3ebc0ba
* Currently, we validate EAS accounts using a command that will
succeed even if we do not support required security policies.
* This causes a confusing "invalid username or password" error
when trying to sync with a validated account in the case that
there are, in fact, required policies
* The fix is to send a sync command after validating the user name
and password; a 403 error indicates the requirement for
security policies.
* When we see the 403 error, we put up a message that is appropriate
to the situation.
Change-Id: Ic40820253dca1f357297b2355ad987bc39d0775f
Merge commit '151ebde5d1135ca7b50ffd97df14cda5d3282477' into eclair-mr2
* commit '151ebde5d1135ca7b50ffd97df14cda5d3282477':
Allow sync data via the chunked transfer encoding DO NOT MERGE
* Fixes#2216885
* The bug is that the sync adapters weren't set up to handle chunked
encoding, primarily because 1) I hadn't seen any servers use it, and
2) when we changed from HttpUrlConnection to HttpClient, support for
chunked wasn't added (HttpUrlConnection didn't support it)
* The fix for xml data is trivial, since the Content-Length returned in
the chunked case (-1) was being disallowed, but works perfectly well
with HttpClient.
* The fix for attachments is less trivial, but still straightforward.
* With this change, we are no longer dependent on receiving content-length,
which is highly desirable
Change-Id: I8d46790e41eaeee2887c8a207006c5d6786498ed
* The prior fix prevented looping in the case that a new sync key wasn't
received.
* Unfortunately, the prior fix tested for the looping condition (moreAvailable)
before it would have been set.
* The correct fix is to detect the looping condition after both the sync key
and the moreAvailable flag are guaranteed to have been set
Change-Id: I2eee4ddc123fb2a5ce4ef3bd4e7d0614fcfbdf36
Merge commit '1b21ad4d4b548784b6974696551c880b1c2eae9d' into eclair-mr2
* commit '1b21ad4d4b548784b6974696551c880b1c2eae9d':
Import corrected translations. DO NOT MERGE
* Fixes#2216885
* The bug is that the sync adapters weren't set up to handle chunked
encoding, primarily because 1) I hadn't seen any servers use it, and
2) when we changed from HttpUrlConnection to HttpClient, support for
chunked wasn't added (HttpUrlConnection didn't support it)
* The fix for xml data is trivial, since the Content-Length returned in
the chunked case (-1) was being disallowed, but works perfectly well
with HttpClient.
* The fix for attachments is less trivial, but still straightforward.
* With this change, we are no longer dependent on receiving content-length,
which is highly desirable
Change-Id: Ie3bd6af0cf68f3afa190711d96b1dbd2e6341f79
Merge commit '68942b93a49c4bfed972ee0b5cffd301cebdacc8' into eclair-mr2
* commit '68942b93a49c4bfed972ee0b5cffd301cebdacc8':
Fix folder deletion; support folder rename (#2118439) DO NOT MERGE
* The fix to bug #2191778 inadvertently broke attachment loading for
Exchange 2003 servers; the server responds with a 403 error (indicating
an authentication issue)
* All other communications with the server work properly
* We use a slightly different set of calls in the case of attachments (we
wanted to change as little as possible in the fix to #2191778) than we
do in the other cases
* The fix here is to use the same calling sequence for attachments that we
use elsewhere
* This fix has been observed to work on multiple servers, and in various
SSL scenarios (on/off, trusted/untrusted)
Change-Id: Ie2804ddcbfa2b10edff42f7a3811734c325e933d
Merge commit 'bb17f149abe263b36eaab1125e12ea266a60306a' into eclair-mr2
* commit 'bb17f149abe263b36eaab1125e12ea266a60306a':
Import revised translations. DO NOT MERGE
* Folder delete had a subtle error that could cause subsequent folder
changes in the same sync to fail (using wrong end tag)
* Folder change (rename, move) wasn't implemented; this was added and
tested. The change is very straightforward and low risk.
Change-Id: I9733dc5da1a535c388e2feb299a641642ba531c2
* Folder delete had a subtle error that could cause subsequent folder
changes in the same sync to fail (using wrong end tag)
* Folder change (rename, move) wasn't implemented; this was added and
tested. The change is very straightforward and low risk.
Change-Id: Id69cee9b99e9a988a176a6525ba9a1615b741c44
Merge commit '0054c1a9e699e5c90daed6fd0a30ffc8aec3955e' into eclair-mr2
* commit '0054c1a9e699e5c90daed6fd0a30ffc8aec3955e':
Go to combined inbox on notify for 2+ accounts (#2147265) DO NOT MERGE
Merge commit '2533132c84b9721b9692b284bbb14e5e0d237237' into eclair-mr2
* commit '2533132c84b9721b9692b284bbb14e5e0d237237':
Server validates even though server address is wrong DO NOT MERGE
* The problem is that PendingIntents aren't updated when a notification
is updated, so the changed extras when a 2nd account gets a new message
aren't seen by MessageList when it's started up upon tapping the
notification (it uses the extras from the 1st account to get a new
message)
* The fix is to use the newish (cupcake) flag in the PendingIntent that
causes the extras in the PendingIntent to be updated
Change-Id: If12d0e7c6d3f256befeca98b560443395820737f
* Fixes#2173664
* Make sure that not only is the OPTIONS command accepted, but that
the server reports EAS versions and commands
Change-Id: Ic29d3eacfdc54d107600afc443964a1e8b3d5e59
* An Exchange log from Moto has shown sync behavior in which moreAvailable
is set to true even though there are no changes in the sync response
(i.e. the SyncKey is unchanged)
* This leads to long-lived looping which impacts battery life
* The fix is to recognize the behavior and prevent looping by
setting moreAvailable = false
Change-Id: Icf45efbc24331c874c820b7b177e39b16df445d8
Merge commit 'ba2d6de4b706cd226d0eb7910fef7ec77866d831' into eclair-mr2
* commit 'ba2d6de4b706cd226d0eb7910fef7ec77866d831':
Import revised translations. DO NOT MERGE
* The problem is that PendingIntents aren't updated when a notification
is updated, so the changed extras when a 2nd account gets a new message
aren't seen by MessageList when it's started up upon tapping the
notification (it uses the extras from the 1st account to get a new
message)
* The fix is to use the newish (cupcake) flag in the PendingIntent that
causes the extras in the PendingIntent to be updated
Change-Id: Ia4ab14954b2c1413526016975216b2516372f2aa
