Modified location of the test to processUploadMessage() method. We do this to
prevent creating multiple EmailContent.Message objects.
Bug: 4096266
Backport from: Id83d3703283c0cd89a60c6210976093d39fb6934
Change-Id: Ie0e9c52182df96617cc942235135ef5ccf865d41
* This fix may resolve the bugs referenced below; the issue fixed
could cause pandemonium after the server commands a wipe of calendar
data and most likely explains these issues (via Occam's Razor)
* Also backport a SQL fix to more reliably delete calendar data
Bug: 4077499
Bug: 4064237
Backport from: I628fb14ea2c04150d4f27341751f0eab61ee33d1
Change-Id: I7667a11663d8720a92b9eba0748f60256a25edba
The attachment info may be null when we attempt to mark them for
downloading. Add a null-check before we try to dereference the info
structure.
Bug: 4053184
Backport of: I831e3abd100664c92f7af585014a03250e40ff64
Change-Id: Iffdf8cdc3a17c0ab691596eb9e240ef87acb2e37
* This happens if an open fails immediately (error message in the
initial banner) followed by a checkSettings.
* The fix is to harden checkSettings to force a clean connection
every time.
Bug: 2170147
Backport of: If7403bf517477d2b03b21d71caab511fe45e234c
Change-Id: Ia6cc0e3ab0c8a8a78b5d8b8fb7b8ba4b4cdd3ef2
When decoding the Email body, email application used google default base64
function. But it caused problem, so particular email did not sync any more.
So we have changed decoding function as a decoder from apache in order
not to occur problem
Change-Id: I7581123f21fbb4015153ca6f4a0c14c0f6a769fc
Signed-off-by: Sang-Jun Park <sj2202.park@samsung.com>
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
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
* 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
* 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
