Merge commit '78f609db56500c01f75ea2d8742468907255f7ba'
* commit '78f609db56500c01f75ea2d8742468907255f7ba':
MessageView: upon delete move to older instead of newer.
Merge commit '9d024a5b4f42d9d7687d06e5f86f9c68f22fccf8'
* commit '9d024a5b4f42d9d7687d06e5f86f9c68f22fccf8':
MessageCompose: fix NPE cased by WebView set to null in onDestroy().
MessageListAdapter.doRequery() is supporsed to do the same thing as CursorAdapter.onContentChanged() does. So the entire method body can be replaced with super.onContentChanged().
Merge commit '27051e480f9cc5396aacc3cc5e520d5875390548' into eclair-plus-aosp
* commit '27051e480f9cc5396aacc3cc5e520d5875390548':
Use correct EAS version in Outbox (fixes#2319892) DO NOT MERGE
Merge commit 'bfc5de35fa08b6e747e5d5afe72bffafca08ce2a' into eclair-plus-aosp
* commit 'bfc5de35fa08b6e747e5d5afe72bffafca08ce2a':
Fix delay sending mail after tapping "Send outgoing mail" DO NOT MERGE
Merge commit 'c874824ca8b76f795575538ffa34138e2de47cad' into eclair-plus-aosp
* commit 'c874824ca8b76f795575538ffa34138e2de47cad':
Don't delete referenced messages from the Exchange server DO NOT MERGE
* The existing flow is badly broken; every "back" causes the user
to leave the setup flow and therefore have to start from scratch.
This is a very bad user experience, as previously entered data is
lost and must be re-entered.
* The fix corrects these problems, allowing the user to back up
through screens UNTIL the account is successfully created.
* After account creation, the user is returned to the proper screen,
depending on whether we're in "eas flow mode" or not
Bug: 2337511
Change-Id: Ie25ac73dfcd8a1dca36e1b31c75ffb22359840d1
Seems like it's the simplest way to make it.
- Base64 no longer implements BinaryEncoder/Decoder. Email app doesn't use them.
- Copied Decoder/EncoderException. Email app doesn't catch them either.
* Addresses #2287439 incompletely
* The most likely reason for a reply/forward to get stuck in the Outbox
is that the referenced message has been deleted from the client, with
the deletion occuring BEFORE the message gets sent (currently, the two
are completely independent)
* This change causes deletes NOT to be sent to the server if the message
to be deleted is referenced by an outgoing message
Change-Id: Iad3777282385bea82276f363d6f95ba8b07cc01c
* Fixes#2317429
* When "Send outgoing messages" is tapped in Outbox MessageList view,
we clear the error state for all "stuck" messages
* We didn't, however, clear the error state of the Mailbox, which doesn't
clear itself until the end of a pingLoop, which can be up to 30 minutes
* The fix is in two parts:
* We clear the error state of the Outbox when a sync is requested by
the UI
* We don't set the error state of the mailbox for non-auth errors when
sending, because we don't want to block OTHER messages from getting sent.
Change-Id: I06d98e54049b01c2156b1bc3ebbccf043e7b93f5
* We inadvertently failed to set the EAS version in EasOutboxService,
so the default of 2.5 is used
* This works, but SmartReply/SmartForward were enhanced in 12.0 and we
aren't taking advantage of those changes
* The fix is to set the version using common code
Change-Id: Ife6689fa9934da42d98a48df74fca90ba6d1718c
* Fixes 2313077
* Broadcast receivers are run in the UI thread, so we must ensure that
any long-running code is executed in a background thread
Change-Id: I9a3d501a308445a84a1baa99fc6abb9feb56ff2d
* Fixes#2317429
* When "Send outgoing messages" is tapped in Outbox MessageList view,
we clear the error state for all "stuck" messages
* We didn't, however, clear the error state of the Mailbox, which doesn't
clear itself until the end of a pingLoop, which can be up to 30 minutes
* The fix is in two parts:
* We clear the error state of the Outbox when a sync is requested by
the UI
* We don't set the error state of the mailbox for non-auth errors when
sending, because we don't want to block OTHER messages from getting sent.
Change-Id: I768138b6f31eb696811aa94f621b6fa758ec1a5e
* Addresses #2226426
* Recognize the case in which there is no EmailProvider Account corresponding
to an AccountManager account (the case being addressed is that of the
EmailProvider database being deleted due to corruption
* In this case, delete the AccountManager account so that the two are in
sync
* Refactor and add unit test for account reconciliation
Change-Id: I356b8bfaa0846f85223cc15994b750df207a63ea
* We inadvertently failed to set the EAS version in EasOutboxService,
so the default of 2.5 is used
* This works, but SmartReply/SmartForward were enhanced in 12.0 and we
aren't taking advantage of those changes
* The fix is to set the version using common code
Change-Id: I3b505448003f340681deeb8fb22e61e9dd8d10a0
* Addresses #2287439 incompletely
* The most likely reason for a reply/forward to get stuck in the Outbox
is that the referenced message has been deleted from the client, with
the deletion occuring BEFORE the message gets sent (currently, the two
are completely independent)
* This change causes deletes NOT to be sent to the server if the message
to be deleted is referenced by an outgoing message
Change-Id: I146f63ab345c07e684790e1d7d1fc08870468bbf
* Addresses #2226426
* If the user deletes Email data, or if data corruption causes
EmailProvider.db to be deleted, we will be in an inconsistent
state with any existing Exchange accounts, since the AccountManager
will still know about them, contacts (and eventually calendar) items will
continue to exist, etc.
* Run an integrity check when the provider is created, deleting any
orphaned EmailProvider.db or EmailProviderBody.db
* Catch SQLiteException's in the Provider and do an integrity check
if any is caught
Change-Id: I47d523b90a6b8f71ba8e13fba4b04846b3da1b1d
turns out the change I submitted before is not required at all. I mistakenly
assumed sqlite wouldn't be able to handle it. but tested it with the latest
version of sqlite 3.6.20. the old style triggers work fine.
* When a mailbox sync is stopped intentionally (for example, if account
settings change), we report a connection error by mistake
* Handle this case properly, reporting "success" (i.e. no error state)
* Remove obsolete comment
Change-Id: I9bec1244267cd2240c369b9b7f905948381a0f91
* Related to MR1 triaged bug 2274389 in which mail was stuck in the
Outbox and wouldn't send
* It turns out an improper constant was being used in the SQL code
for turning off the "error" state flag
Change-Id: Ic1a2e5b9dd34ec3f9d7da0b3d2cd63d77bb7681e
* The "send outgoing messages" button doesn't work in the combined
inbox (the case wasn't handled)
* Add code to loop through accounts, calling the Controller for each
in this case
* Fixes (partially or completely) #2274389
Change-Id: I94e984247d43f93a4d6546b8c10f6ce149b091be
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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: Idef455f3e1170caf4002542ca432d128b3a19e56
Case #1:
* Fixes#2184702
* Messages can be in the base Messages table, but also in
Message_Deletes and Message_Updates; the latter two were not
being purged of deleted messages.
* This CL deletes from all three tables when a Mailbox is deleted
* Also run a check for orphaned deletes/updates when the email
provider's db is first opened
* Unit test updated to check for proper deletion
* Unit test for the provider check for orphans
Case #2:
* Fixes#2184708
* Messages in Outbox/Drafts can get modified or deleted, but the
rows added to the updates/delete tables never get removed because
the boxes don't sync
* Added code to SyncManager.ping (which gets notifications of these
changes) to delete these rows
Change-Id: Ib53e441136b0da1e88bc220150d631999058a8f0
