This doesn't need to be part of the service because the
implementation doesn't need to be different between any
of the different protocols.
Change-Id: Ifddf16dd3ccaf397029f08f6d4283d9a5630f717
This supports the EasService design.
Yes, I just removed a startSync function from this interface last month. No,
I didn't quite know at the time that I'd be adding one back. :)
Change-Id: I19d9c7838473d8982560764fdba0056cba03d132
(cherry picked from commit 4a5b11d650)
the loadAttachment() call. This work was necessary to support
the new EasService & EasOperation infrastructure.
Change-Id: Idd507aec999596ccd4afa5f03ff2b3c2e38a9029
(cherry picked from commit efac8255ed75d22e60036e19e7a95f8407d18ad3)
This call lets the service know that the push settings for an
account have changed.
Change-Id: I7ed41853df6af6762c80283a2a3510ce41551657
(cherry picked from commit 446136a2278652c627068ecddff534de1ad431ab)
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
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/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
I'm formalizing the concept of folders that must exist,
and the list of such folders should be accessible to all
sync adapters.
Change-Id: I9e4d2d51aa495d211eab2d1e36c3fa197a1ac00d
The old callback mechanism is deprecated, in favor of making
calls on the ContentProvider.
Bug: 9842867
Change-Id: I65f559e593cda24456c4ffb96f785e054626dd0b
- Rather than handle by type, do them all at once.
- Simplify when reconciliation happens.
Bug: 9056861
Change-Id: If264678c82c63090246ef8ff857c8e46f6672c85
By the time the remote call actually runs, the account
may be deleted from the DB, so the account id is likely
useless.
Bug: 9021105
Change-Id: If28b4b8c4b5c52be35c6ff68b326c4ea28d7f7b4
This is part of moving away from the explicit setCallback,
which either has race conditions or is very noisy, or both.
(Each IEmailService call that wants callbacks should just
pass the callback explicitly.)
I'm not yet changing how the services actually handle the
call. Each protocol will need to fix this on their own.
Bug: 9735207
Bug: 9842867
Change-Id: If8cf69ffe82f3544ace9e58b1db5a183f38d038a
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
Cache attachments in a email directory when sending to allow sending
to succeed when the content provider has a permission
Bug: 7381557
Change-Id: Icf9faead2048de237228625f998b42feade48978
* Much, much faster
* Remove message length pass and lots of other useless code
* Create pseudo-attachment for long messages (click to download) that
includes size (so user can determine whether it's worth it)
* Handle download of message via pseudo-attachment; real attachments
are then created as necessary.
TODO: Add real UI with UX input (or modify existing to clean up the
loose ends)
TODO: Optimizations for loading the whole message
TODO: Get server delete working (isn't working currently anyway)
Change-Id: I31f3809fc5a2f9fd490d33cfed70d2930654e71d
Anthony Lee