- Now we show separate notification for each account
- New notification has sender photo, sender name, and subject
of the latest email
- Added the NotificationController class, which is intended to manage
all notifications besides "new message" eventually.
The framework doesn't seem to be 100% ready, and it's not clear how to
add the 3rd line in the expanded notification at this point. Need to
revisit it later to verify UI details.
Change-Id: I40193ee372cb6b2b7245c1588890f238b2469699
* EAS can send both "simple password" and a non-zero number of
required complex characters; we're supposed to ignore the
complex character requirement in this case
* Force complex characters to zero if password is "simple"
* Update constructor test to check the fix
Bug: 2903349
Change-Id: I3d42bd3c8f3667d8f3027da9e91e0dd18722d9bf
* In a recent change, we mistakenly removed the logic for handling
too-long inactivity timeouts; we should just fall back to the maximum
since this is stricter than what we're being asked to enforce
* Restore this logic and update the unit test
* The regression was caused by change Ida5663a9, to wit:
Backport: Handle "Allow non-provisionable devices" properly
Bug: 2886746
Change-Id: I99cf9a37441b80477cc1c2c7ec2a78f8a14a83da
- Added unit tests
- I see the "open a cursor, move to the first row, read a column" pattern over
and over. Added a utility method for this. (Let's try not to bloat the
binary by copying code around!)
- Added helper classes for database related tests
- Removed code dup
Change-Id: I380959215cc1661b252158f0f6e35369b499cdf8
* 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
* 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
* Minimum complex characters
* Password history (i.e. disallow re-use of past n passwords)
* Password expiration
* Password expiration is NOT yet supported in the framework; there
is a TODO in this CL and a trivial change will be needed when
support arrives; for now, we report this as unsupported
* The two implemented policies are testable
Change-Id: I477adbc000577c57d1ab1788378c97a60018c10c
* 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: I5f354a0e2d81844aff75d8a8a6de3b97f0020c1f
This reverts commit 3ee0cad5f5.
Because commit 284b62e1b8c3419bfd02c6fea5ba0a68146c06f8 fixes the underlying
conflict between DeviceAdmin policies and apps attempting to disable the
Keyguard Lock, this patch is no longer required.
Accounts with a server policy requiring a device PIN or Password will
now work properly.
Bug: 2737842
Change-Id: I533c27a01a8a331dc11a0cb84bcc78f48edf621c
* The device policies that enforce the use of a device PIN or password
can be sidestepped by apps that implement KeyguardManager.KeyguardLock
* This renders the policies unuseable
* To prevent this, the email app now scans for any packages holding the
DISABLE_KEYGUARD permission. The existence of any non-system app
with this permission will put all security-enabled EAS accounts into
a security hold, and post a dialog describing the problem.
* The user must uninstall any such app(s) in order to sync their EAS data.
Bug: 2737842
Change-Id: I4c96d76b12d9242b5c755dd60d7578a825fae597
We have singletons that store a Context passed to getInstance().
The problem is that when we call them, we casually pass any Context at hand.
If it's an activity (which is often the case), it'll never be GCed.
This CL make them store the application context insteaed.
Change-Id: I1abcc2c08d3f8201416d6c14720f041693823b4e
* SecurityPolicy: Fix bug that prevents any notifications after the
user hits "cancel all" from the notification pane.
* AccountSecurity: If the user cancels the device admin acceptance
activity, repost the notification.
* MesageList: Catch security hold condition when entering a mailbox, and
launch security setup activity.
Bug: 2585159
Change-Id: I60d5d8c693cc5f00fe98a9cc69265802f5bee813
* Simplify the logic in the onDisabled() receiver. Make sure
security policy keys are *always* disabled.
* Eliminate unused variable and unused receiver.
Bug: 2576145
Change-Id: I3665a1d300edfb77e02737c08aee22bc977f4968
* If the server asks for more than we can support, don't throw
and error from PolicySet creation. Let isSupported() do that.
* Overlong password lengths cannot be supported and isSupported is false.
* Overlong timeouts & max wipes can be reduced to supported
amount (this actually increases security) and isSupported is true.
* Clean up an obsolete comment
* Unit tests
Bug: 2567804
Change-Id: I2d664a7f2a315b9f9bdcb867fe2cd98f74de6f66
* Add "vibrate when silent" choice in UI
* Add storage for it in Email's provider. Existing accounts default to
their current settings (always vibrate / never vibrate).
* Respect new mode when notifications are posted
* Updated existing unit tests
Bug: 2457183
Change-Id: I5c933ac39dbef8b2028255f330e0b084a445421a
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
Marc Blank