There is still work to be done here:
* The debug setting is not persisted in Exchange, so if
the exchange service is killed, when it restarts the logging
will not be active.
* Nothing in Exchange actually does any additional logging
if this logging is turned on.
Change-Id: Ic578e6956f70dd47fba9b2895385312f71c47abf
b/13545303
Prior to this change, there is no bound on the number of message
headers we might try to fetch at the same time. Now, we fetch
headers in chunks of limited size.
Change-Id: I06db96eefa8732f970c31fc3617480de40723f2d
b/13362667
Really this is just for testing, the only window setting
that has any affect is SYNC_WINDOW_ALL. At some point we
should revisit the imap sync window strategy, right now
we will sync up to the oldest message currently on the
device, which is potentially a large amount of data.
Change-Id: I00dd59bd084e85bdf80f3991062b84fcd6a12362
When a message is flagged as deleted on the server, but is not yet purged,
we'll see it syncing down with a deleted flag. This change treats that
condition as if the message has been fully deleted.
Also fix a copy/paste error for cleaning up the message modification tables.
b/12367845
b/13137235
Change-Id: Ic741dedc10251775a7afdce171d59efbd2cf1a5f
b/11689324
In Jelly Bean, the hardware button has been redirected to always open Google Now by default. But
Email does run on Ice Cream Sandwich and on that platform the hardware search button should invoke
a local search of Email. The issue at play here was that IMAP accounts weren't reporting themselves
as being capable of a remote server search, even though they are in practice. Adjusting this
capability fixes the issue.
Change-Id: I829d08d3bb9c8d09beacc85fe8b5903a8565d178
Also, clean up when we create and lose track of ImapStores.
Prior to this we were creating them often, and losing track of them,
which renders useless a lot of the complex logic in ImapStore devoted
to reusing connections.
Change-Id: I771d4e46d0c1cb9b605c43d9cbae6e52f5894745
b/11294681
We had some really broken logic about handling search
results.
In IMAP search, we would request, in a single pass,
FLAGS, ENVELOPE, STRUCTURE, and BODY_SANE. BODY_SANE means
the first N bytes of message content, whether it be from
the message text or attachments. This is different from how
sync works: In sync, we get FLAGS and ENVELOPE in one pass,
and in a later pass get STRUCTURE and first body part text
for each message.
If the total size of the message exceeded the maximum limit
for BODY_SANE, then we'd mark the message as partial, which
would cause us to create a dummy attachment in copyMessageToProvider().
This is a weird solution to the problem of POP messages not
being completely loaded, because in POP message body and
attachments can't be requested separately, so the dummy attachment
just signified that we needed to fetch more data.
This system fails completely on IMAP, because just fetching the
rest of the body will not get you the attachments.
But even if that code is disabled, attachments in search results
still didn't work properly. For reasons I don't yet understand,
if we requet both STRUCTURE and BODY_SANE at the same time, either
we don't received the full attachment metadata, or we ignore it, and
only use the attachments whose contents could actually fit in the
limit imposed by BODY_SANE. So attachments that didn't fit,
or didn't completely fit, would either be missing or corrupt
and unretriveable.
So, end result: It's not clear why we were trying to load
BODY_SANE all in one pass, unlike how it works for sync.
In fact, the way sync does it now makes a lot of sense: We
load FLAGS and ENVELOPE data (small) and put the in the DB
immediately so they can be displayed. In the second pass we
load the (potentially large) structure and message body. If this
is the right solution for sync, it's probably the right solution
for search. So now, that's what we do.
There is cleanup I'd like to do post MR1: Some code is duplicated
between sync and search that could be consolidated, but we're in
low risk mode now so I only changed search code.
Change-Id: I11475e290cda04b91f76d38ba952679e8e8964d5
b/11294681
The problem is that when we try to open an attachment for a
message in search results, it fails. The reason is that part of
loading the attachment, we need to open the remote folder the
message is in. For search results, the message's mailboxKey is
the special fake "search_results" folder, which doesn't actually
exist on the server.
For this change, I've added a new column called "mainMailboxKey".
For search results, this column will be populated with the real
mailbox the message is in. It will be blank for other messages.
This is a quick and low risk fix for this bug, but it's kind
of awkward. We would prefer to do one or both of the following
some time after MR1.
1. Make the "search_results" folder be a virtual folder, the same
way that unread, starred, and other virtual folders are. For these,
there is actually no mailbox row in the database, just some
queries that check various flags in the messages and behave
like folders in the UI. The messages actually still reside in the
real folders.
2. Remove the requirement to open the folder at all to load the
attachment.
Change-Id: I825ab846f78bf8b041a5d1d579260dc5d7b4c522
b/11294681
b/11325976
The problem is that when we get a message as part of a search
result, we'll end up deleting that message from the inbox (or
whatever folder it's currently in). This is because there is
a trigger that deletes messages if a new message is inserted
that has the same serverId and account.
Now, messages with duplicate serverId/account combinations are
allowed if one of the messages is in a SEARCH type folder.
Also, make a change so that when a message comes down in
a search result, we do also copy it into the primary mailbox
that message resides in, we only add it to the SEARCH folder.
Prior to this there was some code that intended to put
the search result message into the regular mailbox it's supposed
to be in, so that we'd have correct state in that message.
Unfortunately, there are several problems with this:
1. The code didn't work, it would make a copy in the regular
folder, and then unconditionally move it to the search folder.
2. If we leave this code in place, putting the message
temporarily into the regular folder still activates the duplicate
message deletion trigger, wiping out the original copy, even with
the update to the trigger.
3. It's unclear that it's even desirable to load the search
result message into the regular folder. It could be a very old
message that would not have been synced before, leaving a large
gap in your inbox, which is confusing and could interfere with
IMAP syncing.
Change-Id: I34671a3b677ab42a3efd0d170a6ebd9246ec493d
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
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/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
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
b/10075523
Now, every 15 minutes we'll sync the last 24 hours.
Every 4 hours we'll perform a full sync, which will
take either the last 7 days, or until the oldest message
we already have locally.
Change-Id: Idc55a46a28af2a68cc324e414d51d88373941595
b/10111339
b/10125810
The first problem was that the imap BEFORE clause
is exclusive, so messages on the date given in
BEFORE will not be sent. Now, on the sync for the
most recent messages, we will just not specify a
BEFORE clause, so we can always get the most recent
messages even if our clock drifts from the server.
The second is that some imap servers do not accept
time information on the query dates, and that causes
errors. The imap spec defines the BEFORE and SINCE
clauses to come with a <date> only, not a time,
and although it seems that at least some imap servers
handle that, it can't be expected to always work.
Change-Id: Ibf41c6f7600b9f9537bc6d13b59873ee36798e1e
The old callback mechanism is deprecated, in favor of making
calls on the ContentProvider.
Bug: 9842867
Change-Id: I65f559e593cda24456c4ffb96f785e054626dd0b
There is now only one LogTag class. The static initializer of
GmailApplication (existing) and EmailApplication (new) will now set
the log tag to "Gmail" and "Email", respectively. Up until that code
is run, it will be "UnifiedEmail".
"setprop log.tag.Gmail VERBOSE" (or .Email) will trigger all logs to
be printed as long as they go through LogUtils, regardless of what tag
is used by that individual log. This lets us still turn on logging
everywhere in one command, but also lets us use more descriptive tags
(like the class name).
And since we no longer have three com.android.mail.utils.LogTag
classes, builds will be much easier.
Also, we now use LogUtils everywhere.
Change-Id: I55f1c7a66ce50ead54877a13e40256422a56dc39
- Update syncTime for IMAP and POP whenever we sync.
- Change load more to simply include the delta in the RPC
rather than using the visibleLimit column.
- Add a query to get the message count for a Mailbox.
- Refactor code for updating totalCount and determining
the new message count when syncing.
- Remove dead code from Mailbox.
- Remove uses of visibleLimit from code.
Note that visibleLimit and messageCount in Mailbox table are
no longer useful and will be removed in a later change.
Bug: 8579767
Bug: 8523146
Change-Id: Ieb67e3b6f1c82c3b21b972c5a1e557cd75dc21db
The code for syncing new messages from client to server
somehow never got moved from Email1 to Email2.
This change also includes minor cleanup on system mailbox
flags.
Bug: 8531552
Change-Id: I1f9396635ba14cb6e641d2bc1b506c6d702f6b2e
- Make sure visibleLimit stays <= totalCount.
- Don't reset it to 0 every time user enters a folder.
Also sets Folder.totalCount = Mailbox.folderCount
(rather than Mailbox.messageCount).
BUG: 7480726
Change-Id: Iae084d9445f483dca2b1da052ffd4dd7d091c6f6
* Restore Imap1 code
* Legacy users will use Imap1
* Existing Imap2 users will continue to use Imap2
* New accounts will be created in Imap1
* More to follow
Bug: 7203993
Change-Id: I8b86fcada59a854fd464d5269c94d00ebae85459
* Change getCapabilities API to take an account, rather than
the id of the account
* getCapabilities() can therefore execute even before Exchange
is fully up and running
Change-Id: Id4c2a9942ea7a21e0c56401c50206b680274b43e
This CL includes the following:
* New Imap2.apk generation (not included in builds)
* "Push IMAP" option for accounts when Imap2.apk present
* Account creation/setup
* 2-way sync of messages, deletions, flag updates
* Push (messages, flags)
* Folder list hierarchy handling
* Message text (one plain or html part)
* Picker UI for trash folder (placeholder)
* Capabilities handling/UI command
Major Imap2 new features:
* Push
* Multiple folder sync
* Sync window (like EAS)
TODO:
* Picker UI for sent folder
* Upload of sent messages to server
* Search
* Multiple viewable parts
* Probably lots more, incl. unit tests
Change-Id: Ia5d74073d9c307e0bdae72a7f76b27140dde7d14
Tony Mantler