... when you want wifi to be really most sincerely off, because
settings restore is about to rewrite the conf file.
Bug 9032154
Change-Id: I6a3a34ac3f14ec43aa9d9cc0159fca6168ccd0a2
Make sure that apps that have access to restricted accounts can see them.
If they don't have access, they shouldn't be able to add a new account either.
Show an error message in the account picker if the user/app is not authorized.
Change-Id: I117c0b14d7d06c5ac4e66506df156b174567f5f3
Created constants for these in UserManager and current.txt. Also created
an accessor for individual user restrictions that takes the restriction key
(removing individual methods for particular restrictions).
Change-Id: Ibb5517cbcdffadd3925f52cbe67d7d525813faa9
# By Yevgen Pronenko
# Via Android Git Automerger (2) and others
* commit '3c239d7e8d78570b1e17ad968c408506e73a8f3f':
Disable usage of WAL in DatabaseHelper
# By Yevgen Pronenko
# Via Gerrit Code Review (1) and Johan Redestig (1)
* commit '88ba2f48a2d1193f3877575b2589897a7804aa75':
Disable usage of WAL in DatabaseHelper
insertForUser takes a specified user and attempts to adjust that user's
settings, first looking at their existing settings to determine the difference.
However it was querying the settings for the calling user, rather than for
the user whose settings were being changed.
Also add a test that exercises the fix.
Change-Id: I6ed6fd79154ac1b6e6ab880769ac9081dfff6b80
Also fix a build.
And fix a bug that I think was introduced in the multi-user work
that removed the permission check for writing to settings...!
Change-Id: I5945682faa789ffc78fd3546c0df7d03693f106d
Currently we have an "enhance web accessibility" setting that has to be
enabled to make sure web content is accessible. We added the setting to
get user consent because we are injecting JavaScript-based screen-reader
pulled from the Google infrastructure. However, many users do not know
that and (as expected) do not read the user documentation, resulting in
critique for lacking accessibility support in WebViews with JavaScript
enabled (Browser, Gmail, etc).
To smoothen the user experience now "enhance web accessibility" is a
feature an accessibility plug-in can request, similarly to explore by
touch. Now a user does not need to know that she has to explicitly
enable the setting and web accessibility will work out-of-the-box.
Before we were showing a dialog when a plug-in tries to put the device
in a touch exploration mode. However, now that we have one more feature
a plug-in can request, showing two dialogs (assume a plug-in wants both
features) will mean that a user should potentially deal with three
dialogs, one for enabling the service, and one for each feature. We
could merge the dialogs but still the user has to poke two dialogs.
It seems that the permission mechanism is a perfect fit for getting
user permission for an app to do something, in this case to enable
an accessibility feature. We need a separate permission for explore
by touch and enhance web accessibility since the former changes the
interaction model and the latter injects JavaScript in web pages. It
is critical to get user consent for the script injection part so we
need a well-documented permission rather a vague umbrella permission
for poking accessibility features. To allow better grouping of the
accessibility permissions this patch adds a permission group as well.
bug:8089372
Change-Id: Ic125514c34f191aea0416a469e4b3481ab3200b9
There was no default value for parameter "dock_audio_media_enabled"
in global settings and because of that it couldn't be obtained before
Settings app first start and improper actions, such as FORCE_NONE
sending to AudioSystem instead of FORCE_ANALOG_DOCK, were taken.
This patch sets default value to 'true'.
Change-Id: Idbe343519db15f806f3a237e8b39f8420b9edde1
Signed-off-by: Dmytro Dubovyk <dmytro.dubovyk@ti.com>
Only plays a tone if the battery level is below 95% which
is the same heuristic used when determining whether to turn
the screen on.
Use new low battery and wireless charging sounds on Mako.
Bug: 7371658
Change-Id: Ia4527ec398d024ee418a4287e1fcbf0ec83bcc24
According to SQLite documentation, WAL can not be used when database
partition is not accessible for writing (even when the client just
performs read operation).
However, such situation may happen when the partition is full.
As SettingsProvider should always be able to read a value of ANDROID_ID
from corresponding database, this commit disables usage of WAL.
Without this we risk ending up in a situation where /data is full
and the phone is unable to boot properly.
Change-Id: I1f79bbcd8d0f64bf35dc9d7b846bcfb2664d2eac
Optimize for updating mNetworkPreference according to device's networkAttributes
setting from overlay config.xml when connectivityservice start.
Change-Id: I90286332d4f453038f1ddac7dd9d1265d96b4859
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
This does some cleanup of the initial boot, especially when
booting in "no core apps" mode for encryption/decryption.
Change-Id: Ifb3949f580e52f54559e603c4b0b104f6bac2f6c
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
So that:
- the values can be shared (to fix assoc bug)
- the values can be customized in product overlays
Bug:7373284
Change-Id: I37f037082523a3d975f6014f36afa28c60117372
For some reason, the original step didn't work for some testers. This re-applies the move, which
should be no-ops if the entries are already in the right table.
Bug: 7254629
Also moved a few more entries to the global initialization section. Otherwise they would write
into the wrong table.
Change-Id: Ic0f5c4e09680f5687d08dccf78063508b9c0584c
The last bit of undoing the earlier tangle around query results having
observers under the calling user's identity. We do *not* want to drop
calling identity in the call() processing; we want the table-based
permission checks at the point of the underlying db operations to be
performed against that identity.
Bug 7265610
Change-Id: Ie0c9331ebd0918262a0a32b5b03b876fc2a92ca3
Existing primary users were never being marked as complete,
causing things that relied on this (e.g. showing the quick settings panel)
to break.
Bug:7282088
Change-Id: I9c8622f3cd0fb99a44477946d3db22fa2cbbc6fc
Pro tem, we ignore wifi configuration data when restoring system settings.
This is not ideal, but it *does* mean we do not bounce wifi off and on
again during the extended restore process, which in turn means we don't
interfere with things like the Play Store's download of applications.
We do continue to back up wifi configuration, and will start using that
data again when the new implementation that restores AP configurations
without having to bounce wifi comes to pass.
Also, this CL fixes a longstanding bug in BackupDataInput.skipEntityData()
that was being reproduced reliably once settings restore was skipping
the wifi-related entities in the restore stream.
Bug 7249405
Change-Id: I61520a9a116b66ebdf95734d09d9afd46406df01
The write-permission check must occur after any destination-table
rewriting, otherwise any application would be able to write to
any global setting, by supplying a fraudulent "system" namespace
in the uri, but with a key name that will be redirected to global.
Bug 7289965
Change-Id: I122098a64e40d14e00d3cb6608c50aeb74faf7ce
The Settings put*() APIs fix up references via the old namespaces,
but the raw insert() interface didn't. Now it does. Also, when
possible we fix up direct query() operations on the old namespace
to point to the correct one. At present that is only done for
query() operations with Uris of the form
content://secure/adb_enabled
There is no rewriting done on queries of the form
content://secure WHERE name='adb_enabled'
since the app-supplied WHERE clause can be arbitrarily complex.
Bug 7267568
Change-Id: I5c8cecbea7f5b1da6247a53b1428d3effb0bbca5
The reason for this is a bit subtle: we want to guarantee that
when a content observer is registered using the public API, it
is *always* bound to the host user's view of the data behind the
observed Uri, never the calling user's. Now, the reason it was
the calling user in the first place is that the Settings provider
(and potentially any singleton provider) needs the observers
underlying Cursors returned from query() to be tied to the caller's
user, not the provider's host user.
In order to accomplish that now that the public-facing behavior is
always tied to the host user, the concrete class that implements
the Cursor type handled by the Settings provider has been extended
with a new hidden API for setting a notification observer tied to
an arbitrary user; and then the provider explicitly downcasts the
query result's Cursor to that class in order to register the
notification observer. We can do this safely because this is platform
code; if we change the way that these underlying cursors are constructed,
we can just fix this point of call to follow along. If they get out
of sync in the future, the Settings provider will scream bloody
murder in the log and throw a crashing exception.
Bug 7231549
Change-Id: I0aaceebb8b4108c56f8b9964ca7f9e698ddd91c8
Ringer mode setting was moved from System to Global group
but a db upgrade cleanup step was missing.
Bug 7128886.
Change-Id: Id20994fe74575afa2b68154a620aa3c8807e8304
1) Properly handle restores of settings elements that have been migrated
to the new global namespace
1) Back up and restore the new global settings namespace
3) Make sure to back up / restore the global entity
ENABLE_ACCESSIBILITY_GLOBAL_GESTURE_ENABLED
Bug 7249405
Change-Id: Ibfa9930ea4d0e16c7635697e8c631b155e4c0cb2
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
Migrate networking, storage, battery, DropBox, and PackageManager
related Secure settings to Global table.
Bug: 7232014, 7231331, 7231198
Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
