isUserSwitcherEnabled now returns false if multi-user is disabled(
supportsMultipleUsers() returns false).
Removed GUEST_USER_ENABLED setting and replaced with DPM.getGuestUserDisabled
check. It currently always returns false, but will be replaced with an actual
policy check.
Bug: 17571233
Change-Id: I41853e8b321b2537952cac5d92e88bfdb8cbd9a8
Fixed up the tests and re-enabled it.
Still suppressed one test because what it relies on Settings.Bookmarks
is broken because Settings query format changed.
Fixed a bug in SettingsProvider that the package query is using the
wrong user id.
Bug: 19913735
Change-Id: Ied86a261defba2706f726a13bc32f385f7d93787
The main looper needs to run freely for a moment after disabling
wifi in order for various signals (content observers, broadcast) to
propagate to all the listeners that need to take action for the
wifi stack to shut all the way down. This patch breaks up the
disable-and-rewrite-config sequence of wifi AP restore in to two
distinct operations separated by a moment so as not to block those
necessary messages.
Bug 22979342
Change-Id: I271766cad0e454669a194652fb67f835bb022cd1
We've seen case of it taking longer than 1500ms for the wifi system to
actually shut down after the triggering settings element is written,
so extend the wait time a bit. We've seen it take more than 1500ms
but not more than 2500ms, so that's the new heuristic.
This will of course all become happily obsolete once we start
applying restored AP definitions programmatically rather than by
filesystem-level operations.
Bug 22979342
Change-Id: I6acf1baac23d4100124093128b82abf242b11a0e
changes)
AppOpsManager:
Changed the default operating mode for WRITE_SETTINGS to MODE_DEFAULT from
MODE_ALLOWED.
packages/SettingsProvider:
We no longer do static permission checks for WRITE_SETTINGS in early checks and
defer that to app op when MODE_DEFAULT is returned. For some operations,
checking against WRITE_SECURE_SETTINGS is sufficient.
ActivityManagerService & PowerManagerService:
Incorporated app op checks and handled the MODE_DEFAULT case.
provider/Settings:
Added helper function to do checks on whether app ops protected operations
can be performed by a caller. This includes checks for WRITE_SETTINGS and
SYSTEM_ALERT_WINDOW.
Also added a public API (with javadocs) for apps to query if they can modify
system settings.
Changed the javadocs description for ACTION_MANAGE_WRITE_SETTINGS and
ACTION_MANAGE_OVERLAY_PERMISSION.
Added public API (with javadocs) for apps to query whether they can draw overlays or not,
and also javadocs description on how to use that check.
Change-Id: I7b651fe8af836c2074defdbd6acfec3f32acdbe9
In SettingsProvider, for settings that are cloned from the parent
to the profile:
When the parent value is changed, notify ContentObservers in the
profile as well.
BUG:21414456
Change-Id: Ie0560d1332174499d067db9978553843b640a161
Permission checks are enforced within the SettingsProvider specifically
for SECURE/SYSTEM/GLOBAL. Now WRITE_SETTINGS is runtime, so it shouldn't
apply to all the settings types.
Bug: 22044704
Change-Id: I9ed25d96b2fa4f46d3d049efa4300cd1d37bbd24
The system settings permission is going away and the user will
be able to choose which apps have access to system settings in
the UI. So, if an app is white-listed by the user or being on
the system image, we allow access to system settings. Also if
the caller has the stronger write secure settings permission
we allow changes of the less sensitive system settings.
Change-Id: I7aca958fd0ad2c588117b8c6e44d78eb16d648bc
Now a text value will be written to "value" but a binary value will be encoded
in base64 and stored in "valueBase64".
A null value will have neither value nor valueBase64.
Bug 20202004
Change-Id: I1eae936ff38e3460dc76ca20cc38f8d7e5ec6215
