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
If the account supports smart-forward. The old code assumed
attachments are not removable if the account supports smart-forward,
which is not true. Locally-added attachments should still be removable.
Bug 3505684
Change-Id: Ie6703551800c617dd224957a098311f0c279b3f1
The problem was:
- MessageFileViewFragment.clearContent (A) is called in onDestroy
- MessageFileViewFragment.openMessageSync (B) is called in a bg thread
to load an eml file
- And both try to hold the same lock. (mLock)
- If EML is large enough, B takes _seconds_. If you press back during this,
onDestroy gets blocked trying to lock mLock.
- This could also cause a crash, because the task that runs openMessageSync
won't get cancelled in this case, because that's done in clearContent.
Because of this, the task's onPostExecute tries to touch a UI element
when the fragment is actually being destroyed.
The lock was introduced to protect mFileEmailUri, only to keep the same
semantics for openMessage() as MessageViewFragment. i.e. openMessage can be
called multiple times for the same instance of the fragment.
However, in practice, this won't happen. Unlike the regular message view,
we never reuse MessageFileViewFragment. MessageFileViewFragment instances
are created per message. This lock was just reminiscence from the early
developmen stage.
So, fix is simple -- just remove the lock.
Bug 3500487
Change-Id: If2b22a683666de535454bb1293563796fa7acfd7
For now it only enables it for the main process. I've added a flag
to EmailServiceProxy for EAS, but it's not used in the exchange side.
Bug 3500292
Change-Id: I5b27c69fe7cc995a430e9def54b2463076032c78
On multitouch devices, the zoom icons are not needed (the user can pinch to
zoom in/out). So, we should disable the display of these icons on multitouch
devices.
bug 3405875
Change-Id: I45484cfc622f11c25d3ea7f4c378c3133d7f7de0
There were two TODO's from a prior CL where deprecated HostAuth methods
were removed.
1. Do not use a generated URI to determine if account settings have changed.
Instead, use the HostAuth structure for this purpose.
2. The account key in the HostAuth structure has been deprecated. Remove as
much of it as possible (until the schema of the host auth database changes,
we must still refer to it when adding rows).
In the process, HostAuth tests were broken out into a separate unit test
file.
Change-Id: I4075da09af168f734db7b20a9ef63d4178ac2064
This happens when
- two accounts are configured
- select account 1
- remove account 1, and account 2 becomes active
In this case we failed to select account 2, and the fragments would keep
thinking account 1 was active. (So no mailboxes would be shown--beacuse there
was of course no mailboxes for account 1!)
When the account list changes, the account loader (created in loadAccounts())
automatically reloads the account list, and calls updateAccountList(). If
there're still more than 1 account at this point, updateAccountList() updates
the account spinner on the action bar. This will result in
ActionBarNavigationCallback getting called, which then updates the current
account as expected.
However, if there's only one account left, we hide the spinner and just
set the account name to the action bar title, so
ActionBarNavigationCallback won't get called and the current account
never changes.
In this case we shouldn't rely on ActionBarNavigationCallback but have to
explicitly update the current account.
Bug 3491567
Change-Id: Ia9ba3e1c11248ad5a1ba7e055717c5519d6e4884
Removed the ugly doAutoRefresh() and byExplicitUserAction.
The intention for these was to supress auto-refresh when the message list
opens without any explicit user action, e.g. due to screen rotation.
However, now that we have the RefreshManager.isMailboxStale check with 5
minutes duration, this check is not really necessary. Let's just always
refresh mailbox if it's stale.
Bug 3493134
Change-Id: I6d0365ed7f8092304117d5f619d570b828edf76f
* 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
If the setup activity ever needs to restore itself after being killed, we were
restoring the Activity object's state (i.e. rebuilding the UI) before we
restored the state of our class. Since the Activity necessarily depends upon
our object's state, Bad Things can [and will] happen.
The solution is simple -- save our object's state last, but, restore our state
first.
bug 3476039
Change-Id: I623f1938c2e0f50d660708a7a7ac3eeb4a8f9090
In some cases, the de-bounce flags were not being properly cleared. Namely, on
the outgoing settings screen. We now consistently clear the flags to ensure the
"next" button is always actionalble when it should be.
bug 3425395
Change-Id: Ib8085fb96522158198d9f33a12effef8f65c0d19
The progress bar is not meant to be GONE. Encapsulated the progress view
in MessageViewAttachmentInfo to make sure that won't happen.
Bug 3417034
Change-Id: I1efee089cc7921f4428a38fcbcdc2e8aa3cec9fd
The expanded account spinner is completed, but the collapsed view
needs some more work. (That'll probably be a rather large CL, so I'll
finish it in a separate CL.)
Bug 3434135
Change-Id: Ia732e6b57b8c0d3e1609c3134b26411539ab6a18
The delete policy can only be set for POP3 accounts. However, the delete policy
is used for all legacy accounts (that includes IMAP). As such, we need to make
sure IMAP accounts also have their policy set; even though the setting is not
configurable by the user.
The delete policy does not mean anything for Exchange accounts, so, we do not
need to modify the account setup code for them.
bug 3074164
Change-Id: Iab10d2997404b3b0c10a60a64fb652540c0d2d1a
Without this, there's a small window where a fragment is in a valid
state after openXxx() before the list is loaded.
Bug 3420361
Change-Id: I7f84a94dec1419762aa6b24188c023abe974d2bf
Whenever we remove the "load" and "view" buttons, we should add an "info"
button; where we will inform the user as to why we are preventing her from
seeing the attachment.
bug 3338997
Change-Id: Ic243f1542dec55f5b256eeb67ade50aa90e42009
* When security settings notification is clicked, inform user that
they need to change settings (before dumping them in security
settings.)
* On an authentication failure, present a dialog to the user explaining
that the username or password may be incorrect.
* When the device pin/password is expiring or expired, present a dialog
to the user explaining that it needs to be updated.
Bug: 3238657
Change-Id: I8fca446fa3c1bf87a95938553dbdc362c3df220e
Editing the account description occurs in a different fragment. As such, we
need to notify the fragment in charge of the account list whenever the
description is updated.
We already have a callback mechanism, so, expand that to send notifications
of any property change.
bug 3388586
Change-Id: I02475233f7f333db57c49ceaf908dbfa69c86ca6
if you create an account using one of the pre-defined templates (such as
Yahoo!), the user name and password were not being set in the HostAuth
structure. This was causing an NPE when we tried to generate an IMAP ID.
Change-Id: I9619cddc0ab758c187cf4b9c7c84485ac1f4bfdd
* 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
* No code was harmed, er, changed in the making of this CL
* All that's happened is that code that is needed by both Email and
Exchange have been moved into emailcommon
* This required import changes to many files, which explains the
length of the CL
Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
* 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
* Split PolicySet from SecurityPolicy and move to emailcommon
* Define PolicyService that sync adapter services can use to
interact with the Email DPM administrator
* Implement PolicyServiceProxy for exchange
* Implement PolicyService in email
* Modify imports, references, etc. as required
Bug: 3442973
Change-Id: I92015e21f780a68754b318da89fbb33570f334a2
* Remove LocalStore (pre-2.0 mail database) and its unit test
* Remove UpgradeAccounts (converted pre-2.0 accounts to Provider)
* Remove FolderMessageList (receiver for pre-1.6 desktop shortcuts)
* Remove "upgrading" paths through LegacyConversions
* Clip out dangling references to everything above
Bug: 3292310
Change-Id: I5654d55a0879b00b05b63055b94651855a8ee3ef
- Don't use activity's LoaderManager in fragments. Fragments have their own
loader managers, and using the wrong one causes loaders won't get reset()
when the owner fragment gets destroyed().
- Don't destroy loaders by ourselves.
The combination of these two issues caused the problem where the loader
callbacks wouldn't get the reset event, which resulted in the adapter
holding a closed cursor.
Bug 3412079
Change-Id: Ib7441565ea69adb08eb74845b0996c7b8ae6f53b
At any time, it's possible for the framework to recycle views. Normally it's
not an issue, however, during drag-n-drop a view with "unavailable drop
target" foreground colour may be reused. We need to ensure that the foreground
color is always set.
bug 3398330
Change-Id: I7be9bf8487e0062cf2335476fd971592f33baa09
Todd Kennedy