Callers with INTERACT_ACROSS_USERS_FULL permission can now observe content
for a given user's view (and can notify content uri changes targeted to a
specific user). An observer watching for UserHandle.USER_ALL will see all
notifications for the given uri across all users; similarly, a notifier
who specifies USER_ALL will broadcast the change to all observers across
all users.
The API handles both USER_ALL or USER_CURRENT, and explicitly forbids
any other "pseudouser" designations.
This CL also revs the Settings provider to notify with USER_ALL for
changes to global settings, and with only the affected user's handle
for all other changes.
Bug 7122169
Change-Id: I94248b11aa91d1beb0a36432e82fe5725bb1264f
Various wifi settings that are explicitly defaulted did not get their
default code properly converted to refer to the correct settings
database table.
A collection of moved-to-Global settings that had not yet been
marked @deprecated in the Secure.* namespace are now so marked.
Also updated the namespace used to refer to wifi settings from the
Wifi Service. These changes are cosmetic, but they do eliminate a
number of runtime log messages.
Bug 7153671
Change-Id: I9e5b6464d025cfb480ef97373996e38e82f90593
Oops. Stacked bugs: first, the desired user handle was not properly
being passed from the call() entry point to the database operations;
then on top of that, the client-side cache management was still
looking in the local user's cache for the data, so a request to read
a different user's settings would return the local user's instead if
that key was already known to the local user's cache.
Reads and writes of a different user's settings are now uncached,
so they're relatively much slower. They're rare, however, so this
is not something to worry about unless we encounter a real world
case where it's a significant factor.
This CL also adds a bit of cross-user settings read/write testing
to the existing provider suite. These new tests caught both the
known wrong-user-write bug and discovered the client-side cache
bug, so yay.
Finally, the existing wholesale mutual-exclusion approach would
deadlock in certain circumstances due to the fact that the
settings database creation code might have to call out to the
Package Manager while populating the bookmark/shortcut table,
and the Package Manager would then call back into the settings
provider in the course of handling that request. The synchronization
regime has been significantly tightened up now: now the database
code [which is known to deal with concurrency itself] is allowed
to cope with multiple parallel openers of the same db; this
allows the settings provider to avoid calling out to other parts
of the system even implicitly while its internal lock is held.
Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
Now we can bind to just one instance of DCS, instead of requiring
one-per-user. This also means we can operate on otherwise-stopped
users.
Bug: 7003520
Change-Id: I4881e064ae8942907f6a02c6b868926223455cdc
1. The core accessibility settings required for a blind user to use
the device should not be overwritten on restore. There could have
been enabled via a global gesture from setup wizard, hence the
user definitely needs them. Restoring disabled values for these
settings render the device useless unless sighted help is sought.
bug:7138401
Change-Id: Idc593889aa61fada65b0407623720517c827df53
