If the user revokes device admin status, reset our internal state and
the state of any accounts that might have been depending on it. This
halts syncing immediately and rewinds the security/provisioning state
of any such accounts to a known state (as if the account had just been
created.)
Bug: 2387961
On new accounts, we can accelerate the process of setting up security
by explicitly checking (at the end of the security process). The user
is not required to "answer" the asynchronous notification.
This is an imperfect solution, as a slow initial sync could leave the
user in a non-synced Inbox (with a notification waiting for them), but
we can come back to this after we evaluate real-world performance.
Bug: 2387961
If an account is deleted, immediately recompute the aggregate
security policy, and apply it immediately.
When applying policies, handle "no policy" case by releasing device admin
status entirely.
It turns out that we have already implemented the built-in version of
local-wipe-after-failed-passwords, and the notes about it were not
necessary.
It should be possible to connect to an account with local wipe
requirements and see proper operation.
* Add hold flag to Account flags
* Add code to set it (when EAS reports policy failure)
* Add code to clear it when we see changes from the device admin side
* unit tests
This should be sufficient to restart sync of an account which is on hold
due to security policy requirements. Note, this is considered a "retry",
and if the account still does not meet requirements for some reason, it
is expected that EAS sync will call policiesRequired() again.
* Add more final plumbing for exchange security
* If policies are supported, we now check to see if they are active;
if so, we acknowledge this to the server, after which we are given a
final policy key which can be used for syncing
Change-Id: I5992c790294e35b5ec5343c7665e2e7fd31a75ca
* Create notification to display when syncs fail due to security
* Create psuedo-activity (no UI) to manage device admin state transitions
* Clean up and flesh out SecurityPolicy APIs'
* Add placeholders in EasSyncService showing how to react when policies
are not met and sync cannot continue.
Note: There are some STOPSHIP todo's at the top of SecurityPolicy.java.
These should explain any code that you might think is "missing".
* Begin wiring into system DevicePolicyManager requirements
* Semi-real implementations of isSupported() & isActive()
* Added new API (placeholder) updatePolicies()
* Updated existing unit tests as needed
Bug: 2387961