* 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
* 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
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
* 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
* 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
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
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
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
When downloading attachments in the background, do not display any errors
on the display.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I874ed902bde293303e10308f38b992b2bb15b6aa
* Add simple sanity checks to scanned accounts, skip over if bad
* Fix existing unit tests and add new unit test for this change
* Also fixed minor bug in EmailContent that was never triggered in
production code (only discovered it via a unit test).
* Also fixed minor bug in an existing unit test
Bug: 2937595
Change-Id: Id60bbb5d8bd923db043d46891c7f89d7debb0a11
* DeviceAdminReceiver is actually a BroadcastReceiver, must follow
guidelines to prevent ANR or early process kill.
* Remove all uses of AsyncTask from DeviceAdminReceiver
* Pass all calls through EmailBroadcastProcessorService
* Minor restructuring of EmailBroadcastProcessorService to support
this use.
Change-Id: Ic6257ea5eff1bd466a736e0f93cb89b1cf8aa73e
* Create sync & async versions
* Rename all callsites so sync is very apparent
* Fix callsites appropriately
* Clean up interaction between reconciler and setServicesEnabled
Bug: 3133770
Bug: 3134677
Change-Id: Iefbc7814d9aa390baea6345e450e2a4768bf0a9a
* Make most calls to AccountBackupRestore return immediately w/o DB access
* Move most workers in MailService into async runnables
* Remove account restore / null check from ACTION_SEND_PENDING_EMAIL
* Strengthened unit test on Mailbox.findMailboxOfType() because after
removing the account check (above), sendPendingMessages depends on
findMailboxOfType() returning -1 on a missing account.
* Clean up a bunch of warnings (no longer use deprecated Config.LOGD)
Bug: 3133763 (and probably others)
Change-Id: Id39707bca7a8ebf5000f84d542013411ff0f422e
* Load attachments in the background for IMAP/EAS messages
* Download an attachment from account X if:
1) 25% of total storage free
2) Attachments for X use < 1/N of 25% of total storage, where N is
the number of AccountManager accounts
* Add accountKey to Attachment table for performance
Change-Id: I913aa710f34f48fcc4210ddf77393ab38323fe59
* Detect attachment downloads that have stalled and restart them
* Catch a couple of cases in which we weren't sending callbacks
Bug: 3122242
Change-Id: Id2bfd3b26182004b301cf8665f4feb6e62b98b73
* Hoist wipe() method from AbstractSyncParser to AbstractSyncAdapter
* Add deleteAccountPIMData(accountId) to the EmailService API
* Implement deleteAccountPIMData for EAS
Change-Id: I1037cde25fc2b24419f399446cfa0906dc0174d1
* Remove three unneeded DB lookups
* Eliminate race condition that could cause NPE
* Remove protocol field from report, it wasn't needed (we already
set the sync interval to -1 which has the same effect.)
Note, the problems were introduced unintentionally, due to the merged
result of three different CL's:
I168b3db49bf422b33d05f25cfff1c7be15150c2b
I74a3dae21d9ec16f9903bdf2a1c28092ae89cc50
I53e935f8bf08e0bda6e2cd483229a6377ed39d74
Bug: 3139451
Change-Id: Iadbed267f88808aeace0a2f011e4acf79074af70
* It's possible that endDownload will be called for a request
that has been dequeued.
* Harden endDownload against this eventuality, so that we clean
up properly without throwing exceptions
Bug: 3142618
Change-Id: If61136ed1ea972248fc5f9388beaaf84754f9931
Marc Blank