cause: Work mode is turned on before entering USER_STOPPED state.
Thus, BOOT_COMPLETED broadcast is not sent, but the notification has been dismissed.
use USER_STARTED + USER_UNLOCKED because both are foreground.
Bug: 28864104
Change-Id: I4796b61586e194d8367b9e52a9c56f858cbcbe7d
KeyChain isn't direct boot aware & attempting to bind to a service
inside a dying user isn't going to end well.
Change-Id: I5a0acc34f98c39705ec404765c87e7ac61ca9b71
Fix: 28725354
- TrustedCredential is responsible to show ConfirmCredential
- Show the MonitoringCerInfoActivity in personal side instead to avoid showing work challenge
- put user id into extra
Bug: 28619980
Change-Id: Iedbc0b721ef56675f3c9eb6f1d12daf1222ad080
This reverts commit 895504e55788c5c7fd90830dcf01c41a79ca7fe4.
Also adds a change to device manager to prevent failure there
as in the bug below.
Bug: 28512889
Change-Id: I4a445ec365133e9e2764e2d625d61fc6ee2008ec
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
When both screenlocks for profile user and parent user has been removed (both set to none),
remove CA approvls on that user, and show the "Certificate authority installed" notification.
Bug: 28161447
Change-Id: I3c78dc5cfcdf7c02c91b64abe44984ee790d8f3e
Add test method to remove admins that declare
FLAG_TEST_APP without informing them.
The method will also remove the device and profile
owner status of the admin.
Bug: 28027468
Change-Id: Idb4d3299a9c6595c94bfb424546cd8a384131835
- Returning and accepting CharSequence instead of String
- Enforcing 100% opacity and adjusting javadocs for color
format
- Adding @ColorInt annotations
Bug: 27531295
Change-Id: Id27d4fd5e7bb4d746cc61288457eb4eb86224505
- Show DPC app name for PO
- Check user id for DO
- Update notification title for all cases
- update symbols for private resource ssl_ca_cert_warning changed from string to plural
- Pass number of certificate to MonitoringCertInfoActivity
Bug: 25772443
Bug: 18224038
Change-Id: I68db06f55a24879c1d5f532e38b97e2932bf990e
When an application cannot be started, and there is no profile/device
owner, still return a PackageSuspendedDialog.
BUG: 28042198
Change-Id: I5c30393f9481840a965bb815235af5181561a063
Previously many usages of UserManager.getProfiles and getEnabledProfiles
were only using ids of returned users. Given that the list of users needs
to be parceled and unparceled for Binder calls, returning array of ids
minimizes memory usage and serialization time.
A new method getProfileIds was introduced which returns an array of userIds.
Existing method calls were updated where appropriate.
Bug: 27705805
Change-Id: Ic5d5decd77567ba0f749e48837a2c6fa10e812c0
Settings screen should apply both primary and managed maximum
timeout policy, even separate profile challenge is enabled.
Bug: 27493348
Change-Id: Ia1ec1cafc7665c54816833af64e0f446a77a55b2
Changes:
(1) When unified work challenge is enabled and screen lock is secure
- Store work profile secure key in primary profile
- When primary user keystore unlocked, unlock work profile keystore
- When primary user change lock to none, remove work secure key
(2) When unified work challenge is enabled but screen lock is not secure
- When screen lock changes to secure, store work secure key in primary
(3) When user changes work challenge from unified to separated
- Remove work secure key in primary
(4) When user changes work challenge from separate to unified
- Do (1) and (2)
Bug: 27460698
Change-Id: I8f77bde5dc6b8e59c90256e75c5990100e93366b
1. Fix trust agent config does not persist across reboot
2. xxxTrustAgentConfiguration now supported in parent DPM instance
Bug: 27601827
Change-Id: I6ea4a089bf590d6c44be40318f3a69c35c54f796
If the profile owner wants to set a lock screen for a profile which they
created, we should let them. This will cancel any lock screen
unification that has been set up.
Attempting to clear the password will continue to throw
SecurityException if called from a managed profile.
Bug: 26682008
Change-Id: Ia09aef879a21c074ccb517905e43f62696837998
- Split per user version of getUserRestrictions into a separate method
in DPMS and make the per-user version return null if the admin
parameter is not a valid one.
- Update isAccessibilityServicePermittedByAdmin and
isInputMethodPermittedByAdmin to return false if the admin parameter
is not a valid one.
Bug: 27909087
Change-Id: I6f4cae6552cbfe02dc4a92b04eeeddf0314e0974
Note:
DevicePolicyManagerService is changed to inject ContentObserver notifier
Test: all test cases in DevicePolicyManagerTest pass
BUG: 25710621
Change-Id: I347cec71769d0e9dd6a334d7d6339d5ce6a3fa6a
When installing a keypair the caller will have the option to specify a
certificate chain which will later be returned to whoever requests access
to the keypair via KeyChain.
Bug: 18239590
Change-Id: Id21ef026e31537db38d891cb9b712dd4fe7159c7
