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
