* Remove PolicyService APIs policiesRequired, policiesUpdated,
isSupported, clearUnsupportedPolicies, and isActiveAdmin
* Add PolicyService API setAccountPolicy, which is the sole
method by which security policies are promulgated
* Add protocolPoliciesEnabled and protocolPoliciesUnsupported
to the Policy class; these are packed, localized strings
indicating policies that the protocol itself have enabled
and/or cannot support (i.e. these are policies that are
unknown to the DPM, e.g. don't load attachments)
* Differentiate in security notifications between three kinds
of policy changes - changes that don't require user
intervention (e.g. reducing requirements), changes that
require user intervention (the legacy notification), and
changes that make the account unsyncable (e.g. the server
adding an unsupportable policy). Handle all possible policy
changes cleanly.
* Make security notifications per account (with multiple
accounts, notifications would get arbitrarily munged)
* Expose ALL enforced policies via the account settings
screen in two categories: policies enforced (including
both policies enforced by the DPM and policies enforced
by the protocol) and policies unsupported (note that these
can only be seen if policies are changed after an account
is created; we do not allow the creation of an account
when any required policies are unsupported). Add a
button that forces a sync attempt, for accounts that
are locked out, but whose policies have changed on
the server (this would otherwise require a reboot).
* Updated unit tests
Bug: 5398682
Bug: 5393724
Bug: 5379682
Change-Id: I4a3df823913a809874ed959d228177f0fc799281
This test has been disabled for over a year. I call it unnecessary and a
burdern at this point.
Bug: 2938323
Change-Id: I98bd67a0ed3bb1b880a5e7b6bcf8c90b8cf2de46
This is a theoretically dangerous issue that has surfaced only as a
monkey bug so far. The issue is that callers that create an Intent set
some global state, expecting that state to still be valid when the
Intent is handled. However, if the process was killed before the Intent
could be handled, or if that global singleton was not saved properly,
that state was lost and SetupData was never initialized properly.
Bug: 5337276
Change-Id: I6bd08a0dec13f54c7ba8d536ebdc87e6c559c483
We were unfortunately passing through all touches and never intercepting
events from the message ScrollView. This was desirable when the drag was
over the message content, but in the surrounding chrome it would lead to
pressed states while dragging, sometimes accidentally causing text
selection. This change makes that logic special cased to WebViews only.
Bug: 5361173
Change-Id: Icf535c015cec4a79a5ad7eba3d6c5aa7bd572a8a
