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
b/10968838
The main problem here is that Ui Attachment was always using
a content Uri that was generated using the attachment's account
Id and rowId. This works correctly for attachments in messages
we have received, but it does not work for drafts: Draft attachments
are not stored in the normal place, rather, they are stored in
the cache directory. There is an additional column in the
Attachment table, called cachedFile, which is not replicated in the
Ui attachment. That's okay though, if we have a cachedFile, then
when we are populating a Ui Attachment, we should just use that
for content Uri.
Also, I discoverd that for draft attachments, we were not correctly
setting the account key. That didn't turn out to be the problem,
but I'm fixing it anyway because it will cause problems later on.
Change-Id: I0143ba824f3a5bfcd77f32828931b94d6977626f
Some changes that allow a notification to open Account Settings for a specific
account
Bug: 10930585
Change-Id: Ib329e339b405ccbc0631d5ce6a23bf8fa6d62b83
On updates to content://com.google.android.email.provider/syncedMessage
request a sync for the folder the message is in.
We need to do this because Exchange sync adapter is marked as
android:supportsUploading="false" so notifySync() doesn't work.
Neither does adding a UPLOAD extra to the sync request. If we do that, the
request is dropped.
This means that the sync request will also downsync the folder but t's probably
a good thing anyway.
We could add our own version of UPLOAD extra if we really want to prevent downsync.
Bug: 10678136
Change-Id: I14f06c4da905560716773d31d59388d2e6d25635
I added these to real mailboxes for hierarchical folders, but we
also need them in combined view.
Bug: 10891994
Change-Id: Iaa291fb9a9cd6039fb4d347309ce3a37aa64392a
Use something similar to the sectioned inbox teaser.
This change allows displaying sender snippets in the teaser.
Bug: 9604590
Change-Id: Ib27f002ab8cbd2315d95d46eeb1735aa6b594db5
b/10211620
The problem here is that on app upgrade, we need to change
the types of all email accounts. To do this, we have to
create new accounts and delete the old ones. This resulted
in calendar and contacts data getting deleted.
But we were copying over the last sync keys from the old
account, so on the next sync, we would only get new data.
This means that all of the data that we had gotten on
a previous sync would never be sent again, so calendar
events and contacts would be missing forever.
Now, we just don't migrate the old sync keys. This means
that on the next sync, we'll get all data, and restore
our original state.
This is still not ideal, because it means that any locally
created data that has not yet been synced will be lost
(b/10805685), but it's much better than it was.
Change-Id: I150c4dbdf490a8f3880261e2469795896ebfeab5
b/10602459
It was possible to turn off syncing for an account in global
settings, but we'd continue displaying some sync frequency
in the in-app settings.
Now, we only display the sync frequency if sync is actually
enabled. If it's disabled we always display "never". Also,
when the user changes a sync setting, if it's set to "never",
we leave the frequency in the database as it is, but disable
sync for that account. If it's set to anything else, we store
that in the database and ensure that sync for the account is
enabled. This means we should not have any apparent disagreement
between in-app settings and global settings as to whether or
not syncing will happen.
Change-Id: I1cc54e76aafd25dc4db0f1b713e7d7cbc30bf77f
Also ignore messages without server ids for moves and
state changes.
Also cleanup to match needs of EAS upsync.
Bug: 10678136
Change-Id: Id4d5229b8479e61bd718b707b0d2bc77a9e68046
b/10653370
This prevents NPEs if a serviec happens to still be running
when an account is deleted.
This mirrors a similar pattern in the gmail app.
Change-Id: I6fd8ae5ffe41580df0a321ec22535403e3f32eee
b/10413188
There are still several issues with attachments generally,
but this fixes the most glaring problem: We were short circuiting
in a loop that needed to populate a hash table of remote message
Ids, so not all of them would be present. The later code intended
to load attachments expected it to be fully populated.
There are still several problems, notably that if downloading
doesn't work, it just spins forever, but this fixes the first
problem.
Change-Id: I2b23dcb841edabe108096933fea2350ef61a10f1
We need to track changes that need to be unsynced. Because
Exchange handles moves differently from other changes, we
create two different tables. The tables are structured as
change logs to better handle error cases.
Change-Id: I4df90c75f36707fa117aed9718508426e60e0749
If you went from search results to conversation view, then hit the
back button, we were taking you out of search results to the inbox,
because we didn't know you had search results.
Now, we're tracking this (through the use of a folder type), so we
take you where you should go.
Bug: 10591438
Change-Id: I12ad81323fe3e1f199d9dd06a1a4e18f765b01ee
b/10527550
I'm not yet sure why we're getting this started
in multiple threads, but the methods where the sync
occurs are now synchronized so they can't happen
at the same time.
Change-Id: Icf7afd336ed056bb42df84b8634117afa8f31213
b/10508861
Temporary fix for this.
For some reason, we're getting messages loaded with the wrong
date being stored. If we have a message with date = 0, and we
filter out anything older than 24 hours, then these messages
with the wrong date won't get loaded into our localMessageMap.
Then we won't recognize that message is already present locally,
and we will fetch a duplicate.
I don't yet know why we're getting the date wrong.
Change-Id: Ic91cd263198ee944eddbaf1d90080e8285a5df6a
These settings need to be migrated from the database, not the
SharedPreferences file that likely shouldn't even exist.
Everything added to Account.java was removed in
Ie6ec389b5b5d2e7ab1b299d0877811ae716526e2
when it was believed to be unnecessary.
Bug: 10211615
Change-Id: If6193758febda8a3272d82792492503549a44e32
