DevicePolicyManager:
* getDeviceOwnerLockScreenInfo now returns CharSequence as it returns a string
for display to a user
* setDeviceOwnerLockScreenInfo
** accepts CharSequence, not String as this is a string displayed to the user
** Returns void; throws an appropriate runtime exception on failure
Bug: 27531295
Change-Id: I30528569cfa66ee76f857fbee1c3196f821718fd
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Without logging of setting it's impossible to test the setup, unless
device is rooted.
Bug: 22860162
Change-Id: I0532654ef4e4b7272d2749b30590a1b47da9f645
getStorageEncryptionStatus()
Use StorageManager APIs to get the encryption
state instead of from the system properties
directly.
Bug 26547262
Change-Id: Ic27baa9489d43a93873f8bb0428084f8886aed67
This was logged to often, especially while running CTS hostside tests
and looked too scary to people.
Bug: 27230864
Change-Id: I9e81d9efe87b4aed18aa473be647c560ff9cfa0d
KeyChain can throw an assertion error if
is not around, don't allow that to take down
system.
Bug: 27518175
Change-Id: I99418dfb65c58d3e07cbda91860cdb493b96a836
Since the data returned by these calls can grow unbounded based on
various GET flags, we need to switch 'em over.
Bug: 27391893
Change-Id: Ie849ca30dbaaa91158da4c83675657715629a0ee
What's supported:
- Most APIs are implemented, except for SM.updateShortcuts(),
the icon APIs in LA, and LA.startShortcut().
- Persisting information, except for icons
- Throttling
In addition, now PersistableBundle has a public copy
constructor from a Bundle. (Do we want to @hide it?)
TODOs:
- Add icon support
- Implement missing APIs
- Listen to PACKAGE_* broadcasts and do clean-up
- Support multi-launcher apps (pinned shortcuts per launcher)
- Dev option to reset throttling
- Load throttling config from Settings
- Backup & restore
- Figure out LauncherApps permissions (BIND_APPWIDGETS??)
- Other minor TODOs in the code
- Better javadoc
Note: This requires Idf2f9ae816e1f3d822a6286a4cf738c14e29a45e
Bug 27325877
Change-Id: Ia5aa555a4759df5f79a859338f1dc5e624cd0e35
The main purpose is to fix the security flaw that
user can force isDeviceOwnerProvisioningAllowed to return true
by setting the device_provisioned without factory reset
Check UserSetupComplete instead, as it's cached by DPMS if it's ever set to true
Refactor common code of isDeviceOwnerProvisioningAllowed and enforceCanSetDeviceOwnerLocked
The functionality of enforceCanSetDeviceOwnerLocked should be exactly the same.
DPM Unit Test all pass
Bug:27403225
Change-Id: I32dae8e222e01e08664abb313ead3a92d4186658
Added a check inside PackageManagerService to make sure data for a
package with a DO or PO for the running user is not cleared. Currently,
the 'pm clear' command goes through without any such checks.
Bug: b/27243904
Change-Id: I87d4ad2db031f47946f34627a5ee465ef144f85e
The default value of bluetotoh contact sharing is true.
So we should save when it is false.
Bug: 27410265
Change-Id: Icaf4ceeda09eca46d160acfecc53834819b66a18
If 'requestAccess' is true, the caller (either profile/device owner or a
designated certificate installer) will be granted usage of the keypair
on successful installation.
This has no security implications for a profile/device owner which would
already be able to self-grant. Delegated certificate installers did not
have this ability before.
This is only allowed at install-time- not afterward.
Bug: 24746231
Change-Id: Ia0ec290bb0bcde1d8137c188e2667cb7718dbfd7
After being interrupted the monitor thread tried to acquire
a lock that is held by interrupting thread, resulting in timeouting
on join().
Bug: 27061904
Change-Id: Ifbd578d5f5a266083b207fedd8ebb6d26ab08c31
- Avoid the ART warning about 4.1 compatibility
- Avoid integer overflow in DPMS
Bug 27243525
Bug 27242859
Change-Id: I92af323287e348fbd0eff31e6cf9823be8e41024
Originally I didn't know user-0 could have PO, so I excluded this case
from migration. Now we handle it properly.
Also make sure only restrictions that can actually be set by each
owner moves to the owner restriction. (Because of this, we no longer
have to have DISALLOW_WALLPAPER in the exception list, because
owners can't set DISALLOW_WALLPAPER.)
Bug 27225996
Change-Id: I6ad79d90e6c4400abbb1e4feba6ba59e3b650815
