| 83e03f55597a69bf1e1f2df2cd24e83e84d21914 |
|
16-Mar-2018 |
Maggie <yiranwang@google.com> |
Fix location settings bug on non-GPS devices
The old location_mode API hardcoded gps and network location provider when it enables/disables location, without checking whether the providers exist on device.
It causes bugs when used together with the new
LocationManager.setLocationEnabled() APIs.
This fix modified LocationManager.setLocationEnabled() API when user
tries to disable location on device. Besides turning off the providers
from LocationManager.getAllProviders(), it also turns off GPS and
network provider explicitly.
To reduce times of binding to the service and chance of race condition, we also
modified SettingsProvider.updateLocationProvidersAllowedLocked() to
accept a string param with multiple location providers to be
enabled or disalbed at the same time.
Bug: 73261572
Test: Manual on chromebook
Change-Id: I2e59e0d4cf395b98cd481af5d7f3c762274d7826
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|
| e080da9ee027fcd030aa92ea26fd0ed9f031674f |
|
22-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Settings recovery support
This change allows the system to perform iterative reset
of changes to settings in order to recover from bad a
state such as a reboot loop.
To enable this we add the notion of a default value. The
default can be set by any package but if the package that
set it is a part of the system, i.e. trusted, then other
packages that are not a part of the system, i.e. untrusted,
cannot change the default. The settings setter APIs that
do not take a default effectively clear the default. Putting
a setting from a system component always makes it the
default and if the package in not trusted then value is
not made the default. The rationale is that the system is
tested and its values are safe but third-party components
are not trusted and their values are not safe.
The reset modes from the least intrusive are: untrusted
defaults - reset only settings set by untrusted components
to their defaults or clear them otherwise; untrusted clear
- clear settings set by untrusted components (or snap to
default if provided by the system); trusted defaults - reset
all settings to defaults set by the system or clear them
otherwise.
Also a package can reset to defaults changes it made to
the global and secure settings. It is also possible to
associate a setting with an optional token which can then
be used to reset settings set by this package and
associated with the token allowing parallel experiments
over disjoint settings subsets.
The default values are also useful for experiment (or
more precisely iterative tuning of devices' behavior in
production) as the stable configuration can be set to
the "graduated" safe defaults and set the values to the
experimental ones to measure impact.
Test: tests pass
Change-Id: I838955ea3bb28337f416ee244dff2fb1199b6943
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|
| 43765b77a0286403fd9f7f5305219f0d9a10c953 |
|
31-Aug-2015 |
Xiaohui Chen <xiaohuic@google.com> |
Cleanup USER_OWNER in SettingsProvider[Test]
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
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|
| 3a2c3578ba5bf8642c994fa357a96eaa4a38cdc9 |
|
18-Jun-2015 |
Makoto Onuki <omakoto@google.com> |
Allow binary value in SettingsProvider
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
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|
| 2849465ee19febd5135cb6ab8cb548a3c8ac6a24 |
|
12-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Handle a missed case in query the settings provider
bug:19361521
Change-Id: Ibf4731b5d665563bb87ef93a4cf63e4c4d2e46a4
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|
| 683914bfb13908bf380a25258cd45bcf43f13dc9 |
|
15-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Rewrite of the settings provider.
This change modifies how global, secure, and system settings are
managed. In particular, we are moving away from the database to
an in-memory model where the settings are persisted asynchronously
to XML.
This simplifies evolution and improves performance, for example,
changing a setting is down from around 400 ms to 10 ms as we do not
hit the disk. The trade off is that we may lose data if the system
dies before persisting the change.
In practice this is not a problem because 1) this is very rare;
2) apps changing a setting use the setting itself to know if it
changed, so next time the app runs (after a reboot that lost data)
the app will be oblivious that data was lost.
When persisting the settings we delay the write a bit to batch
multiple changes. If a change occurs we reschedule the write
but when a maximal delay occurs after the first non-persisted
change we write to disk no matter what. This prevents a malicious
app poking the settings all the time to prevent them being persisted.
The settings are persisted in separate XML files for each type of
setting per user. Specifically, they are in the user's system
directory and the files are named: settings_type_of_settings.xml.
Data migration is performed after the data base is upgraded to its
last version after which the global, system, and secure tables are
dropped.
The global, secure, and system settings now have the same version
and are upgraded as a whole per user to allow migration of settings
between these them. The upgrade steps should be added to the
SettingsProvider.UpgradeController and not in the DatabaseHelper.
Setting states are mapped to an integer key derived from the user
id and the setting type. Therefore, all setting states are in
a lookup table which makes all opertions very fast.
The code is a complete rewrite aiming for improved clarity and
increased maintainability as opposed to using minor optimizations.
Now setting and getting the changed setting takes around 10 ms. We
can optimize later if needed.
Now the code path through the call API and the one through the
content provider APIs end up being the same which fixes bugs where
some enterprise cases were not implemented in the content provider
code path.
Note that we are keeping the call code path as it is a bit faster
than the provider APIs with about 2 ms for setting and getting
a setting. The front-end settings APIs use the call method.
Further, we are restricting apps writing to the system settings.
If the app is targeting API higher than Lollipop MR1 we do not
let them have their settings in the system ones. Otherwise, we
warn that this will become an error. System apps like GMS core
can change anything like the system or shell or root.
Since old apps can add their settings, this can increase the
system memory footprint with no limit. Therefore, we limit the
amount of settings data an app can write to the system settings
before starting to reject new data.
Another problem with the system settings was that an app with a
permission to write there can put invalid values for the settings.
We now have validators for these settings that ensure only valid
values are accepted.
Since apps can put their settings in the system table, when the
app is uninstalled this data is stale in the sytem table without
ever being used. Now we keep the package that last changed the
setting and when the package is removed all settings it touched
that are not in the ones defined in the APIs are dropped.
Keeping in memory settings means that we cannot handle arbitrary
SQL operations, rather the supported operations are on a single
setting by name and all settings (querying). This should not be
a problem in practice but we have to verify it. For that reason,
we log unsupported SQL operations to the event log to do some
crunching and see what if any cases we should additionally support.
There are also tests for the settings provider in this change.
Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
/frameworks/base/packages/SettingsProvider/test/src/com/android/providers/settings/SettingsProviderTest.java
|