* 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
* 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
* This fixes the case of:
* a device that does *not* support device encryption
* connecting to an account that *does* require device encryption
* but also supports "non-provisioned devices" (making the encryption
requirement optional.)
* Added unit test
Bug: 3367191
Change-Id: I894e68c4119a102dad02d2e0815fccdae1e87189
* The underlying bug was fixed by bdc in I080147b017b961502b3ba98d40841fea679491eb
This reverts commit 9166aa46da.
Change-Id: I51e7e585e7b1624cc2b08ea81baba6f2602a76cf
* We're seeing our ping timeouts complete after 30 seconds (although
set to 5-17 minutes), due to the fact that our reused sockets are
not having their timeouts reset (i.e. they use the original value
of 30 seconds from when the socket was first created)
* Until the underlying issue is resolved, we'll avoid reusing
sockets for Ping commands
Bug: 3241899
Change-Id: I90b53c0d28b866a91507efafacbb3c4c0df2324c
* Set aggregated expiration values with DPM
* Fix min/max logic when aggregating, and fix unit test
* Add expiration tests when checking if policies are active
* Add expire-password to uses-policies set
* Handle password refresh (clear notifications and sec. holds)
* Handle password expiration (warning and/or wipe synced data)
* Unit tests for provider-level methods
* Refactor common security notification logic
* Placeholder notification strings (need final)
Bug: 3197935
Change-Id: Idf1975edd81dd7f55729156dc6b1002b7d09841f
* 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
* 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
* Hoist wipe() method from AbstractSyncParser to AbstractSyncAdapter
* Add deleteAccountPIMData(accountId) to the EmailService API
* Implement deleteAccountPIMData for EAS
Change-Id: I1037cde25fc2b24419f399446cfa0906dc0174d1
* EasSyncService was using the callback for all syncs, including
those running in the background. We really only want to report
back when syncs initiated by Controller fail...
Bug: 2239661
Change-Id: I7c4aceb74fe94ca38f5bdbbabe5dda62ccac60ec
* 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
* HTTP error 500 occurs with Exchange 2003 when the user tries to
authenticate with wrong credentials; we report this as "Cannot
connect to server", which is wrong
* Error 500 is supposed to mean "internal server error", but since
we know that an authentication error can cause this, we now put
up a better error message
Bug: 2933381
Change-Id: I9319a5ed6fbf4c92739f305b42b6b1cad7036a4b
Merge commit '9b5c615ceea0270878a5b89fc0a063eeb9ffdd3e'
* commit '9b5c615ceea0270878a5b89fc0a063eeb9ffdd3e':
Increase EAS command timeout from 20 to 30 seconds
* Load MIME data for these messages and parse, looking for a body either
in HTML or plain text or both
* If the MIME data had been trunctated and we can't find text, mark the
message as partially loaded and load the body text as we did before
(i.e. get the plain text body); this should be a rare case
TODO: Consider what is testable in the new EmailSyncAdapter code
Change-Id: I00a3066a373a0596431335593de356a4dda7f036
* We were zero'ing the server id BEFORE the move, rather than
afterward; this is fixed in the current CL
Change-Id: I4a5f2b2de5794a110a8f657c80dfeac4955b5909
* Create AttachmentDownloadService to manage all attachment downloads
1) User requested
2) Required for email forwarding
3) Opportunistic downloads to enhance offline use
* New attachment related UI (pending UX approval, of course)
1) MessageView (attachment actions, progress bar, etc.)
2) MessageCompose (attachments for forwarded messages)
3) Associated toasts, notifications, etc.
TODO:
* Unit tests
* Cache Management (separate CL)
Change-Id: I7864a5fb1c3f4f2be68d98341a971edc6cbacfe1
* When a sync fails due to a provisioning error (on initial sync
or after policies are refreshed on the server), sync mailboxes go
into a "hold" state until the security error is resolved. Meanwhile,
the account mailbox handles provisioning. If this is NOT successful,
we put a hold on the account and go through the UI steps of setting
up security on the device. When this is done, we release the hold on
the account, which releases the hold on the mailboxes.
* If provisioning IS successful, however, a refresh of the existing
settings would be an example, we do NOT release the adapters, and
this is the bug we're seeing.
* This CL simply causes any held mailboxes in a successfully provisioned
to be released from the hold
Bug: 2865623
Change-Id: I59e780e9bd4ea908182b786dfd0e5851f5bf5f3b
* Backport from master branch
* Send policy key of "0" when validating; this gets us the policies
even if "Allow..." is enabled (currently, we simply don't see the
policies)
* If we don't support all of the policies, send back the response
code indicating support for partial support. If we get a positive
response back, then we're good to go - the server allows devices
with partial support. Otherwise, we fail as we always have - with
the toast indicating that the device doesn't support required
policies
* Remove PolicySet.isSupported() and ensure proper field ranges
within the constructor
* Update tests as appropriate
Bug: 2759782
Change-Id: Ida5663a9b35c75ecc61a5f442be0bd60b433cb73
* Handle status 5 for Ping command (heartbeat of out range)
* Write unit test for heartbeat reset
Bug: 2834195
Change-Id: Ic7952a4b296cf15c6ba895d6579fe7956b171e5b
* We need to encode the itemId and collectionId for SmartForward and
SmartReply
* Add unit test for the fix
* Small change + test to EasSyncService usage of URI encoding to use
a non-deprecated method
Bug: 2787725
Change-Id: I428b308b56cc359b8cdd9e42bc3f42c65b6797dc
* The setup flow is changed such that the user is asked to activate
device administration before leaving the setup flow, rather than
having to wait for the notification to appear, etc.
* Accounts requiring security are created in a security hold state
to prevent initial sync until device administration is active
Change-Id: I7e33cf98466370ae27414b99018f7aee71e9e237
Marc Blank