* 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
* 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
* Use ConcurrentHashMap; check that this provides enough protection
for all uses
* This resolves known deadlock issues in ExchangeService
Bug: 3371039
Change-Id: Ie4ccbe7cdfe8c3d4ec7a0f789409126c8c09f8c4
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
* Stop running syncs
* Delete all EmailProvider data except the account itself (with
cleared sync key) and the account mailbox (necessary for syncing
to sync after security hold is lifted
Bug: 3245779
Bug: 3253952
Change-Id: Idc208ef5ed85808b085ebab9c26a428fb0451e34
* 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
* In the case in which a sync was requested during an already-running
sync, we weren't passing the request information into the service
Bug: 3143544
Change-Id: I098161830844f604e4aa5b9c067491d2777d78c3
* We used this to ensure that messages placed in the Outbox would
trigger a sync, but this is already handled by a call to
startSync on the Outbox
Change-Id: I90e1b56dd437bbb9e3341bbe4b1ae8245aede891
* Hoist wipe() method from AbstractSyncParser to AbstractSyncAdapter
* Add deleteAccountPIMData(accountId) to the EmailService API
* Implement deleteAccountPIMData for EAS
Change-Id: I1037cde25fc2b24419f399446cfa0906dc0174d1
* An unexpected (runtime) exception during a callback left the
broadcast unfinished, leading to a fatal exception
* Ensure that we always call finishBroadcast()
* Catch RuntimeException in a broadcast call, so that other calls
can be executed
* Addresses one of two issues in the referenced bug
Bug: 3142618
Change-Id: I77166bf927560681a2b189906cd687a6e3585223
* For now, clicking on the notification takes the user to the
Welcome activity, as we don't have final flows for the new
account setup UI
* Need comment on strings; the problem is that notification
text must be rather short if we're to use the standard
notification display. It looks like newer UI will allow
3 lines instead of 2, however.
* Tested w/ IMAP, POP3, EAS, and SMTP
Bug: 2322253
Change-Id: I7ed6fa5599179870cbcdb14af062e956eff37ec5
* It appears as if our running multiple sync threads can confuse the
mobile sync server during a remote wipe (the server expects the next
client response to be an acknowledgment, whereas it might well be
a command or response from a different thread)
* To avoid this, we first put the account on security hold and then
shut down all other sync threads for the account
* After this, we send the acknowledgment and the remote wipe proceeds
normally.
* NOTE: It's possible that, due to the vagaries of multithreaded
operation, one of the other syncing threads could still send a non-
acknowledgment response to the server before our provisioning thread
gets a chance to send its acknowledgment. However, since the other
syncing threads will terminate (and not restart, because of the hold),
the provision/remote wipe/ack sequence will work on the subsequent
attempt
Bug: 2844888
Change-Id: Ib4ffbbc67b681e69176b6c1d5515fa80c7d1e121
Drafts/Trash are not syncable on EAS, but let's kick the callbacks
as the UI is expecting them.
Bug 2989403
Change-Id: I4feac1f0e5471995c14260be6d12329659385e23
* Turns out that we weren't handling one of the cases for YEARLY
RRULE; that in which the date is specified as a day of week plus
week of month
* Also, we weren't always sending the INTERVAL properly in a few
cases
* Fix these issues and add a unit test that confirms the fixes
* Also removed an unused argument in recurrenceParser in
CalendarSyncAdapter
Bug: 2718948
Change-Id: If9146d484218e7d6bd9f5c2305d0e6a216aeed49
Marc Blank