* 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
Specifically, added configuration settings for international Yahoo
domains (e.g. yahoo.ca, yahoo.de, yahoo.fr, etc), including partially
or wholly owned Yahoo subsidiaries; as well as partner domains from AT&T,
British Telecom, and Rogers whose email services are managed by Yahoo.
For domains supporting IMAP, changed to IMAP+SSL for mail handling to
support a better user experience on mobile devices.
Bug: 3258944
Original Author: Kristopher Giesing
Original CL: If5bdc70f70820f3f8aada6d2ee9b0cdb115432b5
Change-Id: Ib117f3755ff9250746f05debd1a6d1cda44c7855
Specifically, added configuration settings for international Yahoo
domains (e.g. yahoo.ca, yahoo.de, yahoo.fr, etc), including partially
or wholly owned Yahoo subsidiaries; as well as partner domains from AT&T,
British Telecom, and Rogers whose email services are managed by Yahoo.
For domains supporting IMAP, changed to IMAP+SSL for mail handling to
support a better user experience on mobile devices.
Change-Id: If5bdc70f70820f3f8aada6d2ee9b0cdb115432b5
* 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
Backport From: Ie9e944bd39f331c2ddc0f0ba303a3d5684f6f033
Change-Id: Ie57f13a5ca2149961a48b99afaebb812f1cbc88e
Merge commit '641ef663f3b141c2ca99fa67db20fcb3608b71e7' into gingerbread-plus-aosp
* commit '641ef663f3b141c2ca99fa67db20fcb3608b71e7':
Import revised translations. DO NOT MERGE
Merge commit '2a08ef0d285ebf9e8fe86afec1ac4732586b7bb5' into gingerbread-plus-aosp
* commit '2a08ef0d285ebf9e8fe86afec1ac4732586b7bb5':
Don't allow MailService to schedule EAS accounts
Merge commit '4a546f5f6e22747304a07ab6892aa318447b5fe7' into gingerbread-plus-aosp
* commit '4a546f5f6e22747304a07ab6892aa318447b5fe7':
DO NOT MERGE: Backport AttachmentProvider security fix
* 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
Merge commit '214c6c6c8173cf90a3e45615a6896a48dc643e68' into gingerbread-plus-aosp
* commit '214c6c6c8173cf90a3e45615a6896a48dc643e68':
Fix remote wipe with mobile sync server
* 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
Merge commit 'efcde27bf74acdd82bb0aad0ad1fd0b767ca5f18' into gingerbread-plus-aosp
* commit 'efcde27bf74acdd82bb0aad0ad1fd0b767ca5f18':
Use original all-day flag when upsyncing exceptions DO NOT MERGE
Merge commit '9c2baaabd2feff633db3ed1b782282667e541927' into gingerbread-plus-aosp
* commit '9c2baaabd2feff633db3ed1b782282667e541927':
Fix upsync of exceptions in EAS 2.5 (Exchange 2003) DO NOT MERGE
* 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
Merge commit '419a36ca6e8d0c46875e82c1e8be245b45adbb52' into gingerbread-plus-aosp
* commit '419a36ca6e8d0c46875e82c1e8be245b45adbb52':
Give email its own version# scheme. DO NOT MERGE