The reason why the UI is wedged is becasue it doesn't
see a state transition in the status. So now we detect the situation
where the user is trying to download an ineligible file and force
the status to indicate that it was a failure to dismiss the UI and
to show the correct error message.
Change-Id: I9264966830a317724bf2fe469ae570860ba7c2a9
the loadAttachment() call. This work was necessary to support
the new EasService & EasOperation infrastructure.
Change-Id: Idd507aec999596ccd4afa5f03ff2b3c2e38a9029
(cherry picked from commit efac8255ed75d22e60036e19e7a95f8407d18ad3)
Queue operations through a single ConcurrentLinkedQueue and
service the updates on a single async task to avoid spamming the
async thread task queue.
b/11336926
Change-Id: I8e5c526d61f70fbad0ccef80afd08fc26bb5acf0
b/11436795
If an attachment download fails due to a timeout, or
an exception being thrown from startDownload(), we'd call
cancelDownload() on it. But this didn't actually cancel,
it would remove it from the inProgres list, but leave it
in the list of all downloads, so we'd immediately retry it.
This is bad for two reasons:
1. It can starve out other attachment downloads that could
have been successful.
2. It will keep attempting to do network work, even if it's
hopeless, forever, draining battery.
Now, if an attachment download fails in this way, for the first
few times, we'll move it to the tail end of the list of
downloads we'd like to perform. If it fails more than 10 times,
we'll give up completely. Giving up is not permanent, if we
have a reason to attempt a download again (such as the user
tapping on it), then it will get added back to the download
service and retried.
Change-Id: I5364a7d8b4b25ce299b8dcf061db6e9ce12daf75
b/11436795
Some of the logging I enabled here actually causes an
exception to be thrown because the format didn't match
the args in the log command.
Change-Id: If86942e64927c0e8df7573ef099824899e20c289
b/11436795
Now, if we ever insert or update an attachment to have
a blank location, we'll log a warning with stack trace.
Also, logging from ADS now uses the same log tag as everything
else, so we'll be able to see it without needing to turn
on some funny log tag.
Change-Id: Ic566cd87e8893128d074b897d7594a01ae12bc8c
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
The old callback mechanism is deprecated, in favor of making
calls on the ContentProvider.
Bug: 9842867
Change-Id: I65f559e593cda24456c4ffb96f785e054626dd0b
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
* Handle startSync and loadMore
* Use SyncManager rather than MailService for periodic sync
and upload sync
* First of many CL's to disentangle sync from UI
* Note that the large majority of this CL is a refactoring
of IMAP specific code out of MessagingController and into
ImapService; MessagingController will eventually be
removed entirely from the app, as will much of Controller
Change-Id: I13546d0694479b33cf93c25920dedc1d38227f6c
* We were using the deprecated ConnectivityManager for this; we should now be
using the setting in ContentResolver
* Also, remove broadcast receiver code that is no longer relevant
Bug: 5405352
Change-Id: I985a95071aea92d235a2708925f775b817ba2328
* This is a serious bug dating back to the first Honeycomb release
* It was possible that a newly created Message could not yet be
committed to the database when the AttachmentDownloadService
tries to download one of that message's attachments.
* ADS, when it sees that the message (apparently) doesn't
exist, deletes the Attachment (it appears to be orphaned)
* The effect is that the user never sees one of the attachments
in a message.
* This bug has been reported externally
* The fix is simply to check for the message's existence before
deciding to delete it (this check will always work properly)
Bug: 4409692
Change-Id: I106ed2fe88d2435ad7a462fced5cb307c2559fd6
* When a connectivity wait was added to processQueue, I neglected
to consider that a lock was held during this time
* The fix is to move the check for connectivity out of processQueue
Bug: 3500702
Change-Id: I646cf899ff895d9838612e89b15b66f1084840b1
* The coup de grâce for Exchange in Email
* Remove Exchange bits from AndroidManifest
* Update Android.mk to create static jar for emailcommon
* Delete all com.android.exchange files
* Delete all exchange-only strings
* Change loadAttachment service method to take only attachment id and
background flag
* Add code to AttachmentProvider.openFile() that opens an output file
for attachment writes
* Make sure deviceId is determined in Email app (not Exchange)
Bug: 3442973
Change-Id: I775600252fd121f474d51cb26fefbfcc50e387af
We're using the mock context to prevent modifying the real databases. However,
we need the real context to create intents. Use the real context in the few
places we must use it.
Change-Id: Icb8d289239218921c0b4b5c93ac7983830d90394
* Make "Exchange" option in account setup depend upon availability of the
Exchange EmailService
* Make presence of Exchange logging depend upon availability of the
Exchange EmailService
* Make AttachmentDownloadService use service rather than ExchangeService
class
* Move SSLUtils to emailcommon/utility
* Move account manager type defs to emailcommon/AccountManagerTypes
* Update proguard.flags
* This is the penultimate CL for the Email package itself; the next CL
creates a clean, SDK-compatible Email application
Bug: 3442973
Change-Id: I9162cf5fa6b5a043ded0fdd1e25fd3ce5948ad8f
* There are three pieces to this CL (sorry):
1) Move and/or rename some constants into emailcommon
2) Move Utility to emailcommon, moving the few UI
related utilities back into Email (FolderProperties
and UiUtilities)
3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
the emailcommon static library to compile cleanly
Bug: 3442973
Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
* Create AccountService.aidl and AccountServiceProxy in emailcommon
* Implement AccountService in email
* Use AccountServiceProxy in Exchange for account reconciliation,
notifications, etc.
* Move sync window constants into emailcommon
* Split attachment provider utilities and constants into emailcommon
Bug: 3442973
Change-Id: I89dce28b799b193243c07774dab65d830ae62775
When creating the list of attachments to be automatically downloaded in the
background, exclude any attachments that are not in an inbox. Also added unit
tests to ensure the query URIs behave as expected.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I13ef56cd280c028fa966ab9e655acce28b0b9b91
Do not retry downloading attachments infinitely. After some number of failures,
black list the attachment and move on. The black list is not persisted, so,
restarting the app will again try to fetch the attachments. In this way, any
transient network failures will not permanently affect the ability to download
attachments in the background
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I7f3ad9667ebebb95fbba95278b62bf40c5fce67c
When downloading attachments in the background, do not display any errors
on the display.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I874ed902bde293303e10308f38b992b2bb15b6aa
Tony Mantler