When processing message updates, we handle messages in the "sent" folder
specially. We continue to do that. However, we must also check that the
given message is still in the "sent" folder.
bug 4096266
Change-Id: Iaa47512fad287e63d8216b755a761b52b324cfff
* 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
* Caught & diagnosed by crash while checking settings
* Also possible in MoveMessageToDialog
Bug: 3412875
Change-Id: Ie78c61cf5ca10ce1eedc25ba2eb97ed0ac5bc615
We would update the attachment buttons if the UI was becoming visible (i.e.
coming back from a settings page), but, we weren't updating them after the
attachment finished loading.
bug 4074694
Change-Id: I9d235620b5a92c2bbb871f70c9d97350cc151ce8
The attachment info may be null when we attempt to mark them for downloading.
Add a null-check before we try to dereference the info structure.
bug 4053184
Change-Id: I831e3abd100664c92f7af585014a03250e40ff64
The problem was that:
- Each account now has own new message notification
- But PendingIntens for these all point to the same activity,
only with different long extras (for acount IDs).
- Framework merges these intents, because extras don't count
as a "difference" in this case.
- So when multiple new message notifications are shown, they'll
all share the same intent internally, so they'll all open the
same account.
A quick workaround seems to be to set a unique URI to each intents.
Bug 3509555
Change-Id: Ib02842bb32634cfdf01ae2d684dd04dfede23832
* Correct allignment of mailbox label
* Sender info & presence alignment fixed
* Header height corrected
* Sender header updated; new asset for background & remove the "fold" asset
* New asset icon and allignment for "show pictures"
* Selected rows have updated background; new assets
* New asset for checked items
* Update divider to be 2px high
* Update selected background for wide message list
bug 3510984
Change-Id: I028ed5619ea7127b0392d9f5b7b00c575b00f3c6
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
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
* 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
Slight API change to make it more clear what the method parameter is for.
Also add some additonal test conditions to the Rfc822Output tests.
Change-Id: I8888d6201e79136fa3420aa9d5f921772f374e56
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
* In the case where there are no Exchange accounts, we can stop ExchangeService
while restoreAccountsIfNeeded is still running, which can cause us to leak
the connection
* Change the call to be synchronous.
Bug: 3495601
Change-Id: I4a396e8b1650bd15fabd2802d2ec8d4276c6e43a
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
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
- Extracted the loader
- Extracted ViewType and introduced WidgetView.
WidgetView is ViewType + mutable fields, such as account id.
WidgetView now owns the method to switch views.
These two are basically in preparation to address the message count bug.
(we're showing total message count where it should be the unread count,
which is a bit tricky because it'll require two different queries.)
- Also simplified the threading model in EmailWidget to fix potential
theading issues. (now (almost) everything works on the UI thread)
Bug 3431240
Change-Id: I9f8a268210995f1135baabe88b49b274272708d4
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
This will be used to set the max width to the account name spinner.
I gave up on writing tests for onMeasure. It wasn't easy without adding
a dummy activity and layout.
It'll be used for a fix to bug 3439694.
Change-Id: Ie7569b0661eb732e270e4521fa0d3306f1bdd12c
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
* Use strings that fit properly in new notifications
* General cleanups & rewrites from Roy
* Remove showWarningNotification() and use postAccountNotification()
This is part I. Part II will add dialogs triggered by some of these
notifications, to provide more explanation to the user of what's wrong
and how to fix it.
Bug: 3238657
Change-Id: Ib51bcb4412f8a09a6f97653f0b5f8642efe2ac1e
* 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
* Add getConfigurationData api to AccountService; this allows clients
to get configuration-related data from the Email app
* We use this so that Exchange can determine whether alternative strings
should be used
Bug: 3442963
Change-Id: Ieea56e3416458dc57699b00c2fc062dfcf7abca9
We support two different ways for an IMAP prefix to be specified:
1. A text field on the IMAP configuration page. This is the most obvious to
the end user. It is also an explicit, manual configuration.
2. RFC2342 defines a NAMESPACE IMAP command to be able to query the prefix
from the IMAP server. This is an automatic configuration without any
user involvement (i.e. the UI will NOT change if a prefix is loaded in
this way)
If the user goes to the trouble of specifying a prefix, we will always honour
it instead of the namespace returned by the IMAP server -- even if the user's
configuration is wrong.
bug 1592696
Change-Id: I6b94c7aaac538f6cd9dc4694b0f1634e8c956bc1
LruCache simply wraps LinkedHashMap for a better API.
Performance/hit rate should not be impacted.
Tracking bug: http://b/3184897
Change-Id: Icbac38d3cea5f8c522df7a883d8e74a8f3786b92
* 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
- Moved to com.android.email.widget
- Extracted nested classes to top-level classes
- Some small clean-ups.
- WidgetProvider and WidgetProvider$WidgetService are left in the original
package to keep compatibility with honeycomb (3.0) release.
This CL is supposed to be pure-refactoring. There should be no
functionality changes.
Change-Id: I37acaa24b6b488724750c0f33374b31fcc433f11
Attachments with no extension and mime type of text/plain need to return the
mime type of "text/plain" instead of "application/octet-stream"
bug 3428076
Change-Id: I00452c908ac0672879d42f4ed9ee574e376eac9f
* 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
Fixes deprecation warnings
NOTE: This does not resolve hostauth deprecation; that will be fixed
in a separate CL.
Change-Id: I47115516da34effbf885615cb439c9d3e6f95b84
This makes it easier for cache experiments to swap out the
LinkedHashMap for another cache.
http://b/3184897
Change-Id: Iacdb266e41f5a98efd9bb30bc09ff8fff5a0a5a9
- 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
* CalendarProvider2 has unusual semantics for its delete operation on
Calendars; this caused the user's calendar NOT to be deleted when
the server commanded a wipe of calendar data. The result was
duplication of events after the subsequent resync
Bug: 3361000
Change-Id: I672034a7a444eb7ebdea60cd6dc66a31087cc6f7
The ContentCache is now an LRU cache. This means we must NOT access the cache
while using any iterator over the cache. In this case, we were calling get()
using an iterator of cache keys.
Change-Id: I2d1feabff7474b6f2a230b98f97df067ab7ccd9c
Only send IMAP ID to servers that include ID in the CAPABILITY response.
Always sending IMAP ID was found to cause problems with some servers.
Better compliance with RFC 2971.
Thanks to Samsung for debugging & reporting this.
Change-Id: I495f80949f9f811470853a1f2f8e506d8236d8cf
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
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: I21acd04584a122c19219f3abb6690bb231bad3a6
* After deleting an account, we need to actually update
the list of known accounts - it's not sufficient to simply
rebuild the headers with one account marked deleted.
* Also remove a couple of obsolete TODO's
Bug: 3382965
Change-Id: I1aa6d88f869f0192b564b538817381efdc5fffe0
* Add check for null Account, as this method can be called from a
background thread, and the Account might have been deleted by the
time we're called
Bug: 3396365
Change-Id: Ie125ed714c73d51beaedc818b6b731cea941666f
If there are no email accounts defined, the widget should show a single string
that allows the user to create a new account. Whenever there are changes to
the defined accounts, the widget(s) will update their headers to ensure they
are only displaying valid information.
bug 3296594
Change-Id: I156c20cfc90692174297a2aededd85775e0ea196
The problem was that CombinedMailboxesLoader used the cursor returned by
super.loadInBackground() (which contains accounts), to build a matrix
cursor (which contains special mailboxes and accounts and will be returned),
and *it closed the first cursor* after building the matrix cursor.
However, because this first cursor is the one that CursorLoader sets an
observer, it shouldn't be closed until the returned matix cursor closes.
In other words the two cursors should have the same lifecycle.
Fixed it by using ClosingMatrixCursor that used by AccountsLoader, which
is doing a similar thing, but properly.
Bug 3387730
Change-Id: I554ade001dc25afa869eefb4dcf9887495e6753e
* Rework the interaction with the Account Manager
* Remove unneeded call to response.onRequestContinued()
* Store response in SetupData so it can survive the entire account
setup flow.
* Explicitly report exit status to acct mgr at known exit points:
* AccountSetupBasics.finish() (fail/cancel)
* AccountSetupOptions.finish() (fail/cancel)
* AccountSetupOptions.optionsComplete() (success)
Bug: 3335128
Change-Id: Ia55724eb1e938f2633c5ff7afb719a879be16a1b
For now just show the account name in parens. I'll ask the design
team for a better layout.
(I don't want to change code too much at this point, so didn't add a
new view for the account name.)
Bug 3366546
Change-Id: I3a5314be4bdfacc2720093511eb03571e91fa963
If the server reports an attachment's mime type as either text/plain or
application/octet-stream, we will try to infer the real mime type using
the attachment's extension. If one cannot be found, we either synthesize
it (if original mime type is application-octet-stream), or, we use the
server specified mime type (if the original is text/plain).
bug 3379416
Change-Id: I331e767ed36e4e17756025cc816bdb7b5a8f0868
The various selection strings were missing a test to only show messages that
have been loaded. This is only important for POP3 accounts.
bug 3377041
Change-Id: I3efe366d09dd547878dc0bf57dff58f76de5cca9
While fixing bug 2981433 in Gingerbread, I discovered one additional
place where passwords were being trimmed. This brings the fix forward
into honeycomb, as well as a new unit test for the fix.
Bug: 2981433
Change-Id: I566f5c0c6693ca7c0069bca9e74f320fca48e600
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
* Add multiline flag to preference xml
* Also, remove display of actual signature in summary, as it
does not properly handle long or multiline signatures.
Bug: 3379235
Change-Id: I84894dbdccee2cd8a8ece05d0b8f7fdcf7b92406
* Bug to fix was that it was looping if the user canceled
password or encryption setup (instead of simply re-notifying.)
* Solution was to refactor all code into a single sequence of checks,
rerun the sequence each time, and set markers to prevent looping.
* Rework needed after the changes in I54f39bc9 which added
encryption support but introduced the looping behavior.
* Removed a UI-thread DB access
Bug: 3346641
Change-Id: I0791d7a16287efecc7121b5ffa0db26ca2b05151
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
