This will keep it from being recreated quite as much while off-thread tasks are possibly mutating it.
Change-Id: Ic9873489906339c33a76b8a600c0fc28016debc4
This just adds an oauth button to the accountSetupBasics
screen, which will launch a webview and go to the google
authentication page.
Change-Id: I09d5182fa6081fb94b40e7910b71afbbee70387e
There is now an xml file that holds parameters for oauth
providers, and entries in providers.xml can specify that
they can use oauth.
Change-Id: Ibce5b207f83ce9c773f8f713be9e73bb068070ed
Also add a loader to AccountSecurity, and ignore when a policy contains unsupported requirements.
b/11790165
Change-Id: Idd651153848eea3216656047c5aba3bbd750ca0a
- Delete accounts, not just account data.
- Wait for PIM data to get deleted before proceeding.
- Reconcile after deleting an account.
Bug: 11856902
Change-Id: Ie52b7c583688bf48a33bcf6b4e555b8c055b476c
This ensures the SuppressNotificationReceiver object quiesces the notification while we're viewing the folder
b/11789666
Change-Id: I98f388844b29458e7ea7deee398f7d8536b1919c
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/11535121
Now we only delete messages with the same serverId and account
if the account is an exchange account.
Change-Id: Ic2ebb465ccdb38724b88daac8ac40771c7a24bed
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/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
For now, it sends the device model name as friendly name, in lieu
of actually having a user-supplied friendly name. This is wrong
for at least two reasons:
1) We need to have an actual user-supplied friendly name, but that's
not easy to find.
2) This really shouldn't be a provider query -- it should be something
the Exchange can know locally (ideally this is a system preference
but that's not currently implemented). This workaround just lets
us have some reasonable value that we can update easily.
Bug: 11161234
Change-Id: If83ad768736de19c9d0e833d1f86a6ce9daf5039
In Gmail, we are adding a setting that automatically shows external
images instead of asking user first. Email app should preserve old
behavior.
Bug 11158252
Change-Id: I8b04a1ec31638d756dfee2da8ab2e8178a709416
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
Handle the following edge cases when a manual refresh is triggered:
* No connectivity
* Low storage space
* Timeout (sync not started)
Bug: 11241113
Change-Id: I580235d633fcb65999c0bfe8bf383c9c8ba72110
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
We used to do N+1 DB queries when our list has
N folders in it. Now just do 1 and be smarter about
how we read our values out of it.
Bug: 11112954
Change-Id: Icde0b979ca985e63d6ceba05c3a63f3a9b7e3566
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/11174975
There are already several database fixing steps that
occur when the database is opened, add another one
to correct uninitialzed mailbox parent keys.
This is because we use a two pass system for adding
mailbox rows, first to insert the rows, and second to
assign parentKeys to child rows. We need two passes
because we may insert a child row before its parent,
so the parent's rowId is unavailble. But if the process
dies before the second step is complete we'll be in
an inconsistent state.
Change-Id: Ifaeeaca7e82c1e99656033bc1a9f25d7acb67517
b/11158759
Make the default sync setting for drafts folders 0
(never automatically sync), and disable the settings
control so that it cannot be changed.
Also add a db upgrade step to set any existing drafts
folders to not sync, and clean up any Exchange synced
draft messages.
Change-Id: I256bde231d722089ef2a623482f570a20eccf1de
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
Launch a 2-second delayed message to send a second notification on the folder change update
b/11027351
Change-Id: Ia0a22be79f4a74c6857517cc21e2313cea9cc0e9
b/11069575
The problem is that the UI_MESSAGE query strips out
any inlined attachments, but the UI_ATTACHMENTS query
does not. This means that we display all attachments
at the bottom, regardless of whether or not they're
inlined, but the formatting is wrong because when we measured
we only had the non-inlined attachments.
Maybe we should not display the inlined attachments at
the bottom, but right now if we do that, it's impossible
to save an inlined image. So for now, I'm just making
UI_MESSAGE query keep the inlined attachments so that
both queries have the same behavior.
Change-Id: I155f5bb74dbfbc8dbf02b56dca58fbca3da5da78
b/10968838
The main problem here is that Ui Attachment was always using
a content Uri that was generated using the attachment's account
Id and rowId. This works correctly for attachments in messages
we have received, but it does not work for drafts: Draft attachments
are not stored in the normal place, rather, they are stored in
the cache directory. There is an additional column in the
Attachment table, called cachedFile, which is not replicated in the
Ui attachment. That's okay though, if we have a cachedFile, then
when we are populating a Ui Attachment, we should just use that
for content Uri.
Also, I discoverd that for draft attachments, we were not correctly
setting the account key. That didn't turn out to be the problem,
but I'm fixing it anyway because it will cause problems later on.
Change-Id: I0143ba824f3a5bfcd77f32828931b94d6977626f
Some changes that allow a notification to open Account Settings for a specific
account
Bug: 10930585
Change-Id: Ib329e339b405ccbc0631d5ce6a23bf8fa6d62b83
On updates to content://com.google.android.email.provider/syncedMessage
request a sync for the folder the message is in.
We need to do this because Exchange sync adapter is marked as
android:supportsUploading="false" so notifySync() doesn't work.
Neither does adding a UPLOAD extra to the sync request. If we do that, the
request is dropped.
This means that the sync request will also downsync the folder but t's probably
a good thing anyway.
We could add our own version of UPLOAD extra if we really want to prevent downsync.
Bug: 10678136
Change-Id: I14f06c4da905560716773d31d59388d2e6d25635
I added these to real mailboxes for hierarchical folders, but we
also need them in combined view.
Bug: 10891994
Change-Id: Iaa291fb9a9cd6039fb4d347309ce3a37aa64392a
Use something similar to the sectioned inbox teaser.
This change allows displaying sender snippets in the teaser.
Bug: 9604590
Change-Id: Ib27f002ab8cbd2315d95d46eeb1735aa6b594db5
