Only send IMAP ID to servers that include ID in the CAPABILITY response.
Always sending IMAP ID was found to cause problems with some servers.
Better compliance with RFC 2971.
Thanks to Samsung for debugging & reporting this.
Change-Id: I495f80949f9f811470853a1f2f8e506d8236d8cf
* Initial account setup screen, password entry field
* When passing the entered password from incoming->outgoing
* When restoring store URI's from HostAuth
This will satisfy the users who insist on leading/trailing spaces
in their IMAP or EAS password. Not supported by POP3 (no quoting).
Bug: 2981433
Change-Id: I16c00bf96382899abb54cb75fcd44cf0f140a660
* Update MockTransport to allow TLS connections
* Test TLS connection in ImapStore unit tests
* The bugfix: Re-query capabilities after closing/reopening parser for TLS
(Note: Actually, this is required by the IMAP RFC 3501, 6.2.1)
Bug: 3315939
Change-Id: I51f838043e87750b5712a1bd2e4f9c821b58c808
We discovered that AsyncTask.cancel() doesn't quite perform as expected;
In particular, if you call cancel() during a particularly slow background
worker, the result is discarded and onPostExecute() is never called. If
the result is an open cursor, then we "leak" by not closing it.
For AccountFolderList, which has a multi-step doInBackground():
1. Check for isCancelled() during the long doInBackground() which will
reduce the number of discarded cursors in the first place.
2. Check for isCancelled() at the end of the long doInBackground() and
if true, close the result cursors and return null.
3. In the existing isCancelled() code in onPostExecute(), close the
cursors.
For other Activities (with simpler configurations):
1. Check for isCancelled() at the end of doInBackground() and if true,
close the just-opened cursor and return null.
Bug: 3088870
Change-Id: Ie63a3197af563baa8bb0fe6f1ef9423e281cbf4c
* Apps trying to open attachments using AttachmentProvider were
seeing SecurityExceptions due to the fact that internal calls
from AttachmentProvider to EmailProvider didn't have their
calling identity saved/restored.
* Updated provider calls so that these calls use the Email
process' identity.
* Backport of Ifb71ad834530c6232728e1aad31439991f8ed379, fixing
2908737
Bug: 3121146
Change-Id: Ifa3a0ca8d3e34733c937d7f8c60f068984e1f4f2
* It appears as if our running multiple sync threads can confuse the
mobile sync server during a remote wipe (the server expects the next
client response to be an acknowledgment, whereas it might well be
a command or response from a different thread)
* To avoid this, we first put the account on security hold and then
shut down all other sync threads for the account
* After this, we send the acknowledgment and the remote wipe proceeds
normally.
* NOTE: It's possible that, due to the vagaries of multithreaded
operation, one of the other syncing threads could still send a non-
acknowledgment response to the server before our provisioning thread
gets a chance to send its acknowledgment. However, since the other
syncing threads will terminate (and not restart, because of the hold),
the provision/remote wipe/ack sequence will work on the subsequent
attempt
Bug: 2844888
Backport From: Ib4ffbbc67b681e69176b6c1d5515fa80c7d1e121
Change-Id: Ie9e944bd39f331c2ddc0f0ba303a3d5684f6f033
* Apparently, Exchange 2003 doesn't like to see Visibility set in
Exceptions
* Apparently, Exchange 2003 likes to see Exception Deleted and
ExceptionStartTime prior to other data
* The word "apparently" is used above to indicate that these
findings are not part of any specification, but have been
determined empirically
Bug: 2775885
Backport of: I163f156675f65c494a59d5233b2b6e23b3f1d6a0
Change-Id: I5d32dea5c3903147725b8df87a71e961a4d78c60
The format string "The server %s requires that you allow it to remotely
control some security features of your phone." was being displayed with
the account name instead of the server name.
Bug: 3011124
Change-Id: I1aadb5790297777831dd69f04ea89641240b7b87
* Makes the side-scrollable again
* Required after making them non-long-clickable
Requires companion change in WebView, to allow touch events while
clickable or long clickable (it had been requiring both)
Bug: 3036477
Change-Id: I4cae46d047f825d2aab08d254287855b187e9207
* Check array returned by split("=")
* Add unit tests for this case
* Also add unit tests for quoting removal
Bug: 3040796
Backport from: I170f3cd483fe35186194edeb0c3142fb0e2e9b75
Change-Id: I32ccbdbc7264a95a9cd279218cae390e65e82eeb
* The meaning of a busy status of "Busy" is uncertain; it could mean
"Accepted" or "Tentative", depending on whether the event was
created via OWA/Outlook or EAS
* We have interpreted it as "Accepted", which prevents the user from
actually accepting the event (as a state change is required for us
to send updates to the server/organizer)
* This CL changes the behavior such that a newly arriving event with
a "Busy" status is shown as "No response" in the Calendar, thereby
allowing the user to pick from any of the three possible options.
Bug: 2811859
Change-Id: I321f714e54e66ee8f40f5e2c00587b98bad71a63
* This gets very confused by the new text copy logic
* Downside is that copy from received message does not work at all
(it didn't work anyway).
* Will fix in next release by redesigning MessageView layout and no
longer wrapping in ScrollView
Bug: 2998892
Change-Id: Icd1219f3c45fd4da9259499e9c8a31ed0d3c4c30
- Merged all three BroadcastReceivers into one.
(Changed class name because old ones may have been disabled.)
- Use IntentService to perform the tasks in a worker thread.
Note the new receiver will never be disabled. We always need to start
exchange.SyncManager.
Bug 2722155
Bug 2416929
Backport of I8241880fc1ee38d85dcdca7e1d46fc2f6b2d375b
Change-Id: I9835cf86846d842e6f2d23014bc0912c3b888a05
* We need to include the intro text (--Original Message--, etc.) to
SmartForwards, and somehow this got in a past updat
* Add unit test for forwarding
* Fix unit test for reply so that it works localized
Backport of I8d92f00d37a434840ec3eb237f3901cd5dc7ad09
Bug: 2477988
Bug: 2685784
Change-Id: I2b6654413a8eb5ca900f958f49ec9eee5161a365
* Add this to processSourceMessage in the reply/forward cases
* Add unit tests for reply and forward case
Backport of I6be8383fe5f217a4bda8e669cb69f439bc8e96b6
Bug: 2734321
Change-Id: Ia59e8c4e2f9663f2a10cff066eddeff80bc06cef
- mConnection.destroyResponses() should be protected with
if (mConnection != null).
When we get an IOException, we close the connection and null it out in
ioExceptionHandler(). So mConnection can be null at any point after
where ioExceptionHandler() first appears.
- ioExceptionHandler should close its parent ImapFolder only if the argument
connection is mConnection.
Methods like exists() may pass an ImapConnection which is not mConnection
to ioExceptionHandler. In which case we don't have to close the ImapFolder.
Bug 2898211
Backport of I8f9f45d91f596bb8da1a1575593e652d66deb643
Change-Id: I070458b5535540aba69ad7eee88bd2af8ad5f7b1
Apparently IMAP servers may return multiple SEARCH responses for a
single SEARCH command, and we need to handle all of them.
Before the IMAP rework there was 3 methods that issued the SEARCH command.
Two of them ware doing it right, but the other wasn't, which was what
I copied from, unfortunately!
In case you're wondering, originally the test for this method was done through
upper methods, e.g. getMessage().
Bug 2911647
Backport of Ia50072944d5b01c1e59541c3a966067b13910cc4
Change-Id: Iab5d3fa21e403f2e1043990112154fbb72322b02
One thing that bothers me regarding the new ImapStore is that there is no
tests to verify if the way how getImapId() uses a vendor policy hasn't changed.
This part is hard to test with a real vendor policy, and it can easily be
overlooked even if it's broken.
This CL offers ImapStoreUnitTests a way to test the interaction between
getImapId() and a vendor policy.
Also fixed a bug in VendorPolicyLoaderTest where it assumed the test apk
package name is "com.android.email.tests", but it may actually be
"com.google.android.email.tests" now. (Broken since the test makefile
used inherit-package.)
Backport of I8feb616ea28cb5cae5b4fba57e363771014ac599
Change-Id: I59536bc9a0e5c09c23eab21cdfb2f8283ef01a42
- This is to make sure we're not touching any ImapResponse that's
already been destroyed.
- I didn't add "is it already destroyed?" check to them
(except for ImapTempFileLiteral), because it can be costly.
Just let NPE be thrown.
Backport of Idc7b88c4844727922841cbad8a106bf781181d45
Change-Id: I9932e78a49784e4218e939a12ebcb9a497c4eb57
Unfortunately it's hard to write tests for this change, but at least
all tests pass with Idc7b88c4.
Backport of If0335a848dfcc23aecea22c21b2cce73dac7ff6f
Change-Id: I6cb3525bc3c67bbf2fb101488bf95edbead5d299
- Replace string literals in ImapStore with constants.
- Simplifies ImapStore.en/decodeFolderName
- Mix cases in the test data to test for case-insensitivity
Backport of I88424357227bcf78528df5e6a1c4ba45d54cc65b
Change-Id: I254fe82324f6ff530e40ca0cff7073f670cf9aa3
- Almost completely re-wrote ImapResponseParser layer
- We no longer use simple ArrayList and String to represent
imap response. We have classes for that. (Type safe!)
These classes are also NPE-free.
(which isn't necessarily a good thing, though)
- A lot of clean-ups and fixes in ImapStore.
- More tests for ImapStore.
Now ImapResponseParser moved to com.android.email.mail.store.imap.parser,
but inside, it's 99% new code.
This CL introduces many new classes, but most of them are small classes
to represent the IMAP response.
Problems that this CL fixes includes:
- Special characters in OK response
- Handling BYE response
- Case sensitivity
- ClassCast/ArrayIndexOutOfBound/NumberFormatException
- Handling NIL/literals at any position
Bug 2480227
Bug 2244049
Bug 2138981
Bug 1351896
Bug 2591435
Bug 2173061
Bug 2370627
Bug 2524881
Bug 2525902
Bug 2538076
Backport of I7116f57fba079b8a5ef8d5439a9b3d9a9af8e6ed
Change-Id: I38b6da7b82110181dc78a2c63c6837c57afa81ae
