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
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
