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
It's possible to have multiple EmailProviders.
Also get rid of references to the multiprocess attribute.
Bug: 10388165
Change-Id: Ic6be363eaee20b3b5deddc7b3054d1a7419483a1
It wasn't working right anyway.
Also, fix a problem where account settings were
not being fully initialized.
Bug: 8384097
Change-Id: Ia60ace2ce618b64fe4ad5ef8d8ac547a086a26d5
b/10380970
This could happen if the response to the POP3
RETR request did not contain a content length.
Change-Id: I99ad93ec71ba917e0f36bee204d7f8d05c79c5ff
We were always allocating a one element array in
a loop. We can just keep create one array and
reuse it.
Change-Id: Ia44f0b711ef48fb87030c3f09f3f9fb654717b7a
The IMAP time based query only takes a date, not a
date/time. This means that if we want to load all
messages since, for example, Aug 11 at 3:00 PM,
we'll actually get all messages since Aug 11 at any time.
Our local query actually took into account the time, so
when we loaded a map of local messages, it would not
always include all of the same messages that the IMAP
query would. This meant that if we processed a message
that was in our IMAP query window but not our local query
window, we'd always think it was a new message even
if it wasn't.
It's easy enough to increase the size of our local query
window so that it will definitely include all of the
messages the IMAP query might return, but this adds
a new problem: It's no longer safe to delete any local
message that did not come back in our IMAP query result.
Since our local query may include a larger time window
than the IMAP query window, we need to check each message's
timestamp, and only delete it if it is inside the remote
query time window.
Change-Id: Ib3c1bbe8f3db05720d32a981483676afa6d6c38b
Tony Mantler