* 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
Backport of 47da97527b547da97527b5bbecba972e0c6a5d382cd7b0768e9.
Original comment:
Improve visible difference between read and unread messages
BUG: 2168155
This removes the word "account" to eliminate the need for translation and to simplify
the use of overlays for vendors that need to customize these strings.
* 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
* 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
* 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
* 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
* 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
* For each attachment we add, check the DB for an existing attachment
with similar metadata (name, mime type, content id, etc.)
* Skip adding them if already held
* Unit tests
Originally fixed in 5b0a12c199 / CL I036f39c6
Fixes bug http://b/2084704
* Fixes a bug that caused some attachments to be labeled with the
wrong content type and thus unable to be opened by local apps.
* When the attachment code was written, MimeTypeMap had very few
entries, so we tried to get the mime type of Exchange attachments
from the stream when the file was read off the server. It turns
out that the server's idea of mime type is unpredictable
* In the meantime, MimeTypeMap has been fleshed out, so we really
do know the type in the vast majority of cases (and including all
common document types)
* The fix is to remove the lines related to reading the mime
type from the attachment stream
* Content type is set (properly) when attachment record is created. See
EasEmailSyncParser.getMimeTypeFromFileName() for details.
Fixes bug http://b/2182955
Change-Id: Iebb3de529df4548327d7112e1dedb3bd448462a4
* If we close the activity while a requeryList() is pending in the
handler queue, we'll eventually try to operate on a closed cursor
when we get to testMultiple().
* The fix: Return immediately if the cursor is not available.
Fixes bug http://b/2180416
Followup for bug http://b/2149083
* Relates to a number of bugs related to ANR's and slow behavior
when addressing mail
* Call changeCursor(null) on the Adapter when the activity is destroyed
* Call getCount() in the background thread to force data there rather
than in the UI thread
* If this change is accepted, something equivalent should be
used in the Gmail app as well
* Addresses #2180237 (P1, target Eclair_Sholes) as well as
#2180976 and #2146926, the latter two of which were fixed
with workarounds.
Change-Id: I7503c5fbe091dbc5e784d5a7bebeb3d60226d57d
* Don't runAsleep unless this is a Ping
* Relates to #2178288 in that it's possible that the system could
sleep while we're trying to send (not sure if this is possible;
will check), so we prevent it by holding a WakeLock in this case
Change-Id: Ib3f8786501b942e1cfcb7a0bbb07b8e3084e2a86
* Standard Exchange command timeouts are 20 seconds
* For sending, however, these need to be significantly longer to
handle the case of sending large attachments, as sending (of any
length) happens in a single HTTP Post command
* Having an infinite timeout leads to the (small) possibility of the
Outbox hanging for a long time, holding up the sending of other
mail, so we set a long, but not infinite timeout for this case
* Timeout now set for 15 minutes
* Prevent sync of Outbox and Drafts (the UI triggers these by changing
the contents of these boxes, but we need to ignore the pings that
are generated this way)
Change-Id: I5b830d6b4e94525d95138b2112be12898a37882e
Merge commit '20b3ba2303da8b790afedf84bd20f370bbdf703b' into eclair
* commit '20b3ba2303da8b790afedf84bd20f370bbdf703b':
Import revised translations. DO NOT MERGE
Some IMAP servers return NIL if you BODY.PEEK[TEXT] a messsage with
no body, instead of the more canonical {0}CRLF. Instead of messing with the
parser to deal with that, it makes more sense not to try and fetch empty
bodies. So there are three changes:
* Don't fetch parts when size = 0
* Don't append "null" when there is null body text
* Slight change to attachment handling so size is reported >0
* Unit tests on some of the related lower-level protocol stuff
Bug http://b/issue?id=2160387
Change-Id: Ifb8fb0ed5ce7297908e1ae8d5a02dda5975c4a3c
