The logic is simplified by creating database rows for new mailboxes down
in Imapstore. This means that the difference between local and remote folder
lists are mailboxes that need to be deleted.
Note -- this is still not the final CL. We probably update the database too
frequently and the column values aren't updated to support nested folders.
Change-Id: Ifbe4e0cf74ba81e5b6156b452ab72c56c35235ab
There's no need to create a URI just to rip in appart again. Additionally, to
support additional changes (i.e. to use Mailbox instead of Folder in the
MessageController), we need to store the actual Account.
NOTE -- This change only affects IMAP and POP3. SMTP will come in a follow-on CL
Change-Id: I400036a17271c99272fd9c603547dcd713b50b9d
ListStateSaver did nothing more than hold a Parcelable, and was a
Parcelable itself. The abstraction may have been useful at some point,
but that time seems to have passed.
Change-Id: I2f1f45828782ab44aa8935aa50b825e07845a2a5
- adds a compile time dependency to the guava library
- changes to use @VisibleForTesting in places to ensure it works
Change-Id: I2c5c4f9861234fec3613da011185e5c11f228466
If a mailbox doesn't have any sub-mailboxes, only allow selecting them to view
any contained messages. Do not update the mailbox list.
Change-Id: I6f469bf20a57dc440885402084c21ff184f13dff
mPreviousMeetingResponse is tied to the current response state, so it
should be reset too when we clear the response checkboxes.
Bug 4132763
Change-Id: If816706f47f8500441330882fb4f372b31465ff5
* Add utilities for adding highlighting markup to HTML and
highlighting spans to plain text (for Webview and UI,
respectively)
* Rename Snippet.java to TextUtilities.java and move to utility
package
Change-Id: Ic443ab5ce9c0199fa82a68e1592bf259494cadd2
On exchange servers that support "smart reply", the original message is
actually appended by the server. In this situation, we should not append
the original HTML text on the client.
but 4177192
Change-Id: I6fad74ac761e2abfe7cb0f536df4db30f7d5ca9a
When copying messages between mailboxes using standard IMAP, we must perform
a QUERY or FETCH in order to determine the new message UID. However, if the
server supports the UIDPLUS capability, the server will return the new UID
as part of the response to the "UID COPY" command.
This is the first of a couple modifications. We still need to fallback to a
less efficient QUERY/FETCH if the server does not support UIDPLUS.
bug 4092301
Change-Id: I9279f7fd70daf85adba3b3e202c12d67ddf91f22
Refactor the changes introduced in Ib02842bb.
- Now Welcome and AccountSettingsXL accept intents with URLs of the following
style, and get IDs from query params, rather than extras.
Welcome:
content://ui.email.android.com/view/mailbox?ACCOUNT_ID=1&MAILBOX_ID=2&MESSAGE_ID=3
AccountSettingsXL:
content://ui.email.android.com/settings?ACCOUNT_ID=1
- Now the "new message" and "login failed" notifications use these new style
intents, so the system wouldn't merge PendingIntents for different accounts.
Also:
- Moved all notification creation logic to NotificationController.
(Except the one in CalendarSyncEnabler; which is used only to support
upgrading from pre-froyo and I don't think it's worth refactoring.)
- Note the "password expired/expiring" and "security needed" notifications
aren't changed; they still use extras to store account IDs. This is okay
because these notifications are not per-account.
Bug 4065269
Change-Id: I70737438d2e7c45fd7488a5b0a7105c8568e02f7
* We needed to set DevicePolicyMnager.PASSWORD_QUALITY_COMPLEX
* Setting this, we also need to clear some of the defaults for complex
mode that are not correct for Exchange's definition of "complex".
* Unit tests
Bug: 4092218
Change-Id: Iea7bd05d48f1aa9406222c1db5937cfd7f2662b8
Inline images can be specified in two different ways -- explicitly with a
Content-Disposition of "inline" or implicitly with no Content-Disposition.
We correctly handled the former. For the later, we now default to an "inline"
disposition if one was not specified. This is acceptable per RFC 822 which
states:
Content-Disposition is an optional header field. In its absence,
the MUA may use whatever presentation method it deems suitable.
Additionally, if the disposition is not specified by the server, we need to
look at the Content-Type header for the file name.
bug 2824698
Change-Id: I146f7a67197b4e737e5f82a3d570e0f74e23fa35
* If we read a null deviceName, delete the file and create a
new one.
Bug: 3506362
Backport of Ida670db2f4b75cb9c94636a0af541ae5df50addf
Change-Id: If844fe2a2f3d7096a8b18e826a3640a7d9dff830
To determine mime-types of attachments from the ACTION_SEND and _MULTIPLE intents,
- Use ContentResolver.getType() for content: URIs
- Use inferMimeType() for file: URIs
Tested with Gallary and Downloads.
Bug 3510624
Backport of Ibfa4b383463f157e18fd634e55f5be4b9adf6aa5
Change-Id: Id2815738673f3822a97e92414b84f6a5d46eb96f
To determine mime-types of attachments from the ACTION_SEND and _MULTIPLE intents,
- Use ContentResolver.getType() for content: URIs
- Use inferMimeType() for file: URIs
Tested with Gallary and Downloads.
Bug 3510624
Change-Id: Ibfa4b383463f157e18fd634e55f5be4b9adf6aa5
When replying or fowarding an HTML message, we now send both plain text and
HTML bodies as a multi-part mime message. We take special care to ensure the
message bodies are in their own multi-part block and do not interfere with
any additional attachments to the message.
bug 3060920
Backport-Of: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719
Change-Id: I89ec2795b55ceb7472a8ee3db2dc8f50cf537d9c
The new class EmailAsyncTask might look overkill, but
this is what I've been wanting for long time.
In many activities we store all AsyncTasks we start to member fields
so that we can cancel them in onDestroy(). (e.g.
MessageViewFragmentBase.mLoadMessageTask and mReloadMessageTask)
With EmailAsyncTask these fields will no longer be necessary.
We'll be able to just fire up as many AsyncTasks as we want, and clean them
up in onDestroy() with just cancellAllInterrupt().
Bug 3480136
Backport of Id8aa1ba1500eee58cfab8b562b95e9ed852b3e29
Change-Id: I2d2966ff878862a5246c031d1d4e221da5a7e81a
The new class EmailAsyncTask might look overkill, but
this is what I've been wanting for long time.
In many activities we store all AsyncTasks we start to member fields
so that we can cancel them in onDestroy(). (e.g.
MessageViewFragmentBase.mLoadMessageTask and mReloadMessageTask)
With EmailAsyncTask these fields will no longer be necessary.
We'll be able to just fire up as many AsyncTasks as we want, and clean them
up in onDestroy() with just cancellAllInterrupt().
Bug 3480136
Change-Id: Id8aa1ba1500eee58cfab8b562b95e9ed852b3e29
When replying or fowarding an HTML message, we now send both plain text and
HTML bodies as a multi-part mime message. We take special care to ensure the
message bodies are in their own multi-part block and do not interfere with
any additional attachments to the message.
bug 3060920
Change-Id: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719
* This is is a minimal implementation that only supports the external
encryption policy when there is no physical/removable storage, and
the emulated external storage is located within an encrypted backing
store.
Bug: 3351426
Change-Id: Id96e9277f810beeebf816a914acd3d733eb713ea
