If we have image/* attachments with "Content-Disposition: inline" we would
fetch the images immediately, then drop them on the floor instead of saving
them to the DB.
Add code to catch these attachments and save them.
b/13132802
Change-Id: I5203bb1aa518aa46cdb3a38ead6f79af63b521ac
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
Load large attachments from a partial POP message
There will be a new change that improves the UI for loading
the rest of the message
Bug: 8651782
Change-Id: I075de1e82e27cf2018607eef50143850e8fecaf2
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
Moved two files out of Email into UnifiedEmail and
removed their dependencies on EmailContent. As a result,
those classes now return the data directly via a data only
class.
Change-Id: Iaf0618dd6879c9dc2a41943d3d15428904b65768
* 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
Tony Mantler