b/11224731
There is a problem in ImapService.processPendingUploads().
It was trying to process updates to existing messages
as uploads. This is wrong, it means that marking a sent
messages as Read can cause it to be uploaded again,
resuling in a new message being created.
Change-Id: I502df52a7b315daeee10c1041db8f30dbfd2c04e
We used to do N+1 DB queries when our list has
N folders in it. Now just do 1 and be smarter about
how we read our values out of it.
Bug: 11112954
Change-Id: Icde0b979ca985e63d6ceba05c3a63f3a9b7e3566
b/11183568
We were surrounding the data parameters with
double quotes. Apparently some servers do not
accept this, and they aren't present in the
imap spec.
However, we've been running with the quotes
for several months now, and it seems to work
on most servers. I'm afraid of changing this
right now, it might cause other servers to fail.
So now we'll try the query without quotes, and
if we get an exception, fall back to the old
style query with the quotes.
Change-Id: Ifb7b1a6dd4a9f7bb6b38bd1611c64e2bddb2e188
b/11174975
There are already several database fixing steps that
occur when the database is opened, add another one
to correct uninitialzed mailbox parent keys.
This is because we use a two pass system for adding
mailbox rows, first to insert the rows, and second to
assign parentKeys to child rows. We need two passes
because we may insert a child row before its parent,
so the parent's rowId is unavailble. But if the process
dies before the second step is complete we'll be in
an inconsistent state.
Change-Id: Ifaeeaca7e82c1e99656033bc1a9f25d7acb67517
b/11158759
Make the default sync setting for drafts folders 0
(never automatically sync), and disable the settings
control so that it cannot be changed.
Also add a db upgrade step to set any existing drafts
folders to not sync, and clean up any Exchange synced
draft messages.
Change-Id: I256bde231d722089ef2a623482f570a20eccf1de
This is related to b/11081672.
The logging needed to track this down was tied to
MailActivityEmail.DEBUG, which is tied to a setting that
no longer exists.
Change-Id: I0a23508832ead6ab3cc613a82e0831986b0af49b
b/11081672
Prior to this, any time the AttachmentDownloadService
got a CONNECTION_ERROR, it would just instantly retry,
without any limit on the number of tries. This is bad
if the server is in a funny state, we'll just keep spamming
it with multiple connection attempts per second. Also,
this kills the client device's battery and responsiveness.
Now, it will retry instantly five times, and then retry on a
10 second delay 5 more times. After that it will give up.
Even if it gives up, if the user visits an email with an
attachment, or taps on an attachment to expand it, we'll
start the process over. So we shouldn't have permanent
apparently data loss, even if we fail on the first 10 tries.
I'm not certain that this is the best backoff/limit policy,
maybe we should add a delay after even the first connection
error. But I'm hesitant to change this at this point, it's
possible that something is relying on this behavior and
we don't have a lot of soak time left.
Change-Id: I53d75d5d214ccca887a89cf65b799fe640cc9bc5
Launch a 2-second delayed message to send a second notification on the folder change update
b/11027351
Change-Id: Ia0a22be79f4a74c6857517cc21e2313cea9cc0e9
b/11069575
The problem is that the UI_MESSAGE query strips out
any inlined attachments, but the UI_ATTACHMENTS query
does not. This means that we display all attachments
at the bottom, regardless of whether or not they're
inlined, but the formatting is wrong because when we measured
we only had the non-inlined attachments.
Maybe we should not display the inlined attachments at
the bottom, but right now if we do that, it's impossible
to save an inlined image. So for now, I'm just making
UI_MESSAGE query keep the inlined attachments so that
both queries have the same behavior.
Change-Id: I155f5bb74dbfbc8dbf02b56dca58fbca3da5da78
Tony Mantler