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
