Update the location settings permission related tests that had subtle problems masked by the missing verification step.
Test: Local test run (see http://sponge/7afe8338-24ce-4b98-b400-84373f506885).
Change-Id: I9e3c492f5ee990f248951489adbeb477f2527b42
If a user enables navbar magnification on their new device and the
setting was disabled on their old device, we don't want to overwrite
this setting and disable it on their new device during d2d restore.
Bug: 79189332
Test: 1) atest SettingsHelperRestoreTest
2) manual:
- Source device setting off -> target device turns setting on in SUW
-> d2d restore does not overwrite
- Source device setting on -> target device does not turn setting on
in SUW -> d2d restores setting properly
Change-Id: I58648010a9d4d3380c1c01cdaaab03828e3ea2c4
accessibility_display_magnification_scale has a default value set, so
the current check to see if it was already configured during restore
always falsely returned true. Now, we compare it to the default value
and only say it's configured if different from the default.
Bug: 72737403
Test: 1) Manual d2d restore:
a) Set non-default value on source -> correctly restores on target
b) Default value on source -> correctly has default value on target
c) Set non-default value in SUW during restore -> correctly does not
override with value from source
2) Unit: atest SettingsHelperRestoreTest
Change-Id: Ie0670aac7b4ce806ac7b8baef4eb15a7c40d5919
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
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: I4233b9091d9066c4fa69f3d24aaf367ea500f760
Previous changes statically included legacy-android-test in preparation
for removing android.test.* and junit.* classes from the android.jar.
Unfortunately, that lead to duplicate classes between APKs and the
bootclasspath which caused build problems (Proguard) and also runtime
problems (when targeting and running on older releases).
Switching from statically including the classes to using the runtime
libraries cannot be done in one step because legacy-android-test is
statically included in libraries which are used in many APKs and so
removing it from those libraries requires that all APKs be updated at
once. Doing that atomically across dozens of projects is not practical.
This change modifies APKS that statically include the
legacy-android-test library indirectly.
* If the APK manifest uses the android.test.runner library then the APK
is modified to stop statically including legacy-android-test and
instead build against android.test.base/mock/runner libraries instead.
* Otherwise, the APK statically includes legacy-android-test.
Also, any libraries that statically include are modified to stop
statically including it and if it has source dependencies on the classes
is changed to build against the android.test.base/mock/runner libraries.
The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.
* cmds/uiautomator/instrumentation/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because uiautomator-instrumentation is not a package so does not
need to statically include the classes
* cmds/uiautomator/library/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
uiautomator.core has a source dependency on its classes
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because uiautomator.core is not a package so does not need to
statically include the classes
* core/tests/BroadcastRadioTests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
BroadcastRadioTests's source depends on its classes and because of
these changes they are no longer present on the compilation path.
The classes do not need to be statically included because the
classes will be provided by the runtime, either from the default
bootclasspath or from the android.test.runner library that
BroadcastRadioTests specifies in its manifest.
* core/tests/coretests/Android.mk
Added 'android.test.base' and 'android.test.mock' to
LOCAL_JAVA_LIBRARIES because FrameworksCoreTests's source depends
on their classes and because of these changes they are no longer
present on the compilation path. The classes do not need to be
statically included because the classes will be provided by the
runtime, either from the default bootclasspath or from the
android.test.runner library that FrameworksCoreTests specifies in
its manifest.
* core/tests/featureflagtests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksCoreFeatureFlagTests's source depends on its classes and
because of these changes they are no longer present on the
compilation path. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that FrameworksCoreFeatureFlagTests specifies in its manifest.
* core/tests/systemproperties/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksCoreSystemPropertiesTests's source depends on its classes
and because of these changes they are no longer present on the
compilation path. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that FrameworksCoreSystemPropertiesTests specifies in its manifest.
* core/tests/utillib/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because frameworks-core-util-lib is not a package so does not need
to statically include the classes
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
frameworks-core-util-lib has a source dependency on its classes
* core/tests/utiltests/Android.mk
Added 'android.test.base' and 'android.test.mock' to
LOCAL_JAVA_LIBRARIES because FrameworksUtilTests's source depends
on their classes and because of these changes they are no longer
present on the compilation path. The classes do not need to be
statically included because the classes will be provided by the
runtime, either from the default bootclasspath or from the
android.test.runner library that FrameworksUtilTests specifies in
its manifest.
* location/tests/locationtests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksLocationTests's source depends on its classes and because
of these changes they are no longer present on the compilation
path. The classes do not need to be statically included because the
classes will be provided by the runtime, either from the default
bootclasspath or from the android.test.runner library that
FrameworksLocationTests specifies in its manifest.
* lowpan/tests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksLowpanApiTests's source depends on its classes and
because of these changes they are no longer present on the
compilation path. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that FrameworksLowpanApiTests specifies in its manifest.
* packages/Osu2/tests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
OsuTests's source depends on its classes and because of these
changes they are no longer present on the compilation path. The
classes do not need to be statically included because the classes
will be provided by the runtime, either from the default
bootclasspath or from the android.test.runner library that OsuTests
specifies in its manifest.
* packages/SettingsProvider/test/Android.mk
Replaced 'legacy-android-test' with 'android.test.base' in
LOCAL_JAVA_LIBRARIES because SettingsProviderTest's source depends
on its classes. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that SettingsProviderTest specifies in its manifest.
* services/tests/notification/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksNotificationTests's source depends on its classes and
because of these changes they are no longer present on the
compilation path. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that FrameworksNotificationTests specifies in its manifest.
* services/tests/servicestests/Android.mk
Replaced 'legacy-android-test' with 'android.test.base' and
'android.test.runner' in LOCAL_JAVA_LIBRARIES because
FrameworksServicesTests's source depends on their classes. The
classes do not need to be statically included because the classes
will be provided by the runtime, either from the default
bootclasspath or from the android.test.runner library that
FrameworksServicesTests specifies in its manifest.
* services/tests/shortcutmanagerutils/Android.mk
Added 'android.test.runner.stubs' to LOCAL_JAVA_LIBRARIES because
ShortcutManagerTestUtils has a source dependency on its classes
* tests/AppLaunch/Android.mk
Replaced 'legacy-android-test' with 'android.test.base' and
'android.test.runner' in LOCAL_JAVA_LIBRARIES because AppLaunch's
source depends on their classes. The classes do not need to be
statically included because the classes will be provided by the
runtime, either from the default bootclasspath or from the
android.test.runner library that AppLaunch specifies in its
manifest.
* tests/Camera2Tests/SmartCamera/SimpleCamera/tests/Android.mk
Replaced 'legacy-android-test' with 'android.test.base' in
LOCAL_JAVA_LIBRARIES because SmartCamera-tests's source depends on
its classes. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that SmartCamera-tests specifies in its manifest.
* tests/ServiceCrashTest/Android.mk
Replaced 'legacy-android-test' with 'android.test.base' in
LOCAL_JAVA_LIBRARIES because ServiceCrashTest's source depends on
its classes. The classes do not need to be statically included
because the classes will be provided by the runtime, either from
the default bootclasspath or from the android.test.runner library
that ServiceCrashTest specifies in its manifest.
* tests/net/Android.mk
Added 'android.test.base' and 'android.test.mock' to
LOCAL_JAVA_LIBRARIES because FrameworksNetTests's source depends on
their classes and because of these changes they are no longer
present on the compilation path. The classes do not need to be
statically included because the classes will be provided by the
runtime, either from the default bootclasspath or from the
android.test.runner library that FrameworksNetTests specifies in
its manifest.
* tests/testables/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because testables is not a package so does not need to statically
include the classes
Added 'android.test.mock' to LOCAL_JAVA_LIBRARIES because testables
has a source dependency on its classes
* tests/utils/testutils/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because frameworks-base-testutils is not a package so does not need
to statically include the classes
Added 'android.test.base' and 'android.test.mock' to
LOCAL_JAVA_LIBRARIES because frameworks-base-testutils has a source
dependency on their classes
* wifi/tests/Android.mk
Added 'android.test.base' to LOCAL_JAVA_LIBRARIES because
FrameworksWifiApiTests's source depends on its classes and because
of these changes they are no longer present on the compilation
path. The classes do not need to be statically included because the
classes will be provided by the runtime, either from the default
bootclasspath or from the android.test.runner library that
FrameworksWifiApiTests specifies in its manifest.
Bug: 30188076
Test: make checkbuild
Change-Id: Ia6a48234f28e7e1789049cf4b37cd7fe0bc8251c
The locales are merged with following policy.
- Don't change UI locale.
- Don't add unsupported locales.
- Don't add duplicated locales.
Bug: 35391006
Test: com.android.providers.settings.SettingsHelperTest
Test: Did the following tests manually.
1. Login with Google account during SUW.
2. Set locale to "zh-TW,en-US"
3. adb shell bmgr backupnow com.android.providers.settings
4. fastboot flash userdata && fastboot reboot
5. adb reboot bootloader
6. fastboot flash userdata && fastboot reboot
7. Choose "Japanese" as the first menu on the SUW.
8. Backup from cloud with logging in to the Google account.
9. After compete SUW, verify the device locale is "ja-JP,zh-TW,en-US"
Change-Id: I1e6c7ba5b7abb6bde8b01ce0f647c04a5caa81a6
A previous change added legacy-android-test as a static dependency to
all packages that build against the current, test_current or
system_current and failed to compile when the junit and android.test
classes were removed from the API. Unfortunately, those changes did not
take into account that some of those packages target earlier API
versions and so will always have the classes available at runtime.
This change replaces those static dependencies with dynamic dependencies
for any package that targets an earlier API version. The file changes
were made automatically by a tool that constructed and then analyzed a
full dependency graph of all the Android Java modules. The individual
changes were checked manually to ensure that the changes matched the
intent. The affected modules were built against an API with the junit
and android.test classes removed. Any issues found during this process
resulted in either the tool being updated to address the issue or a
separate change being made to fix an existing problem with the build. A
sample of the affected packages were run to ensure that they worked as
expected at runtime; no issues were found during testing.
The following change descriptions were generated automatically and so
may be a little repetitive. They are provided to give the reviewer
enough information to check the comments match what has actually been
changed and check the reasoning behind the changes.
* packages/SettingsProvider/test/Android.mk
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because SettingsProviderTest's manifest file (AndroidManifest.xml)
targets API level 21 and dynamically includes the
android.test.runner library at runtime so there is no point in
statically including the classes.
Added 'legacy-android-test' to LOCAL_JAVA_LIBRARIES because module
SettingsProviderTest uses classes from package android.test
(possible indirectly) and needs them available at compile time.
Dependency 'legacy-android-test' is used instead of
'android.test.runner' because the latter will conflict with
dependencies on junit.
* services/tests/servicestests/Android.mk
Replaced 'android.test.runner' with 'android.test.mock' and
'legacy-android-test' in LOCAL_JAVA_LIBRARIES because module
FrameworksServicesTests uses classes from packages android.test and
android.test.mock (possible indirectly) and needs them available at
compile time.
Dependency 'legacy-android-test' is used instead of
'android.test.runner' because the latter will conflict with
dependencies on junit.
They were not added to LOCAL_STATIC_JAVA_LIBRARIES because
FrameworksServicesTests's manifest file (AndroidManifest.xml)
targets API level 26 and uses the android.test.runner library which
will provide the classes dynamically at runtime.
Dependency 'android.test.mock.sdk' is used instead of
'android.test.mock' because module FrameworksServicesTests builds
against internal jars not the API and so should use libraries that
build against internal jars not the API.
* tests/AppLaunch/Android.mk
Replaced 'android.test.runner' with 'legacy-android-test' in
LOCAL_JAVA_LIBRARIES because module AppLaunch uses classes from
package android.test (possible indirectly) and needs them available
at compile time.
Dependency 'legacy-android-test' is used instead of
'android.test.runner' because the latter will conflict with
dependencies on junit.
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because AppLaunch's manifest file (AndroidManifest.xml) targets API
level 24 and dynamically includes the android.test.runner library
at runtime so there is no point in statically including the
classes.
* tests/Camera2Tests/SmartCamera/SimpleCamera/tests/Android.mk
Replaced 'android.test.runner' with 'legacy-android-test' in
LOCAL_JAVA_LIBRARIES because module SmartCamera-tests uses classes
from package android.test (possible indirectly) and needs them
available at compile time.
Dependency 'legacy-android-test' is used instead of
'android.test.runner' because the latter will conflict with
dependencies on junit.
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because SmartCamera-tests's manifest file (AndroidManifest.xml)
targets API level 17 and dynamically includes the
android.test.runner library at runtime so there is no point in
statically including the classes.
* tests/Compatibility/Android.mk
Replaced 'android.test.runner' with 'legacy-android-test' in
LOCAL_JAVA_LIBRARIES because module AppCompatibilityTest uses
classes from package android.test (possible indirectly) and needs
them available at compile time.
Dependency 'legacy-android-test' is used instead of
'android.test.runner' because the latter will conflict with
dependencies on junit.
Removed legacy-android-test from LOCAL_STATIC_JAVA_LIBRARIES
because AppCompatibilityTest's manifest file (AndroidManifest.xml)
targets API level 21 and dynamically includes the
android.test.runner library at runtime so there is no point in
statically including the classes.
Bug: 30188076
Test: make checkbuild and ran a sample of tests
Change-Id: I3d183a96bf87437028a2d4b774d311e40349f4d0
The previous change was reverted as it broke work profile provisioning.
Clearing binder calling identity before calling into settings provider
should fix the issue.
Test: runtest managed-provisioning
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: Manually tested that work profile is inflated with expected values
of install_non_market_apps
Bug: 33947615
Bug: 35590590
Change-Id: I3c31a73fef0c25c0e682e18f637272adad39b28d
This reverts commit 2e7d6d64b9.
Bug: 35590590
Fix: 35590106
Test: runtest managed-provisioning
Test: manual verified that work profile can be inflated
Change-Id: Ie780b94053e65bca2f96b32055937c0c9e8beae8
Starting from O, install_non_market_apps is deprecated and will not be
checked by the package installer. Device admin apps should be using the
user restriction instead.
Since on managed profiles, the default value blocked install from
unknown sources, the system will set the user restriction on behalf of
the profile owners (if the profile has one).
For non-managed profiles, the user had access to the settings to change
the value of install_non_market_apps. So going forward, any request to
change it's value by dpm#setSecureSetting in such users is going to be
ignored.
Test: Manually tested that:
1. For a profile with PO, when install_non_market_apps was set to 0,
user restriction is set on upgrade
2. For a profile with PO, when install_non_market_apps was set to 1,
user restriction is not set on upgrade
3. After upgrade, newly created managed profiles with PO have user
restriction set
Bug: 33947615
Change-Id: I063e9ee608b52086ffdf8ed2b24e2928574c58cd
Apps targetting Android O or higher should use the new api
canRequestPackageInstalls in package manager. The secure setting
INSTALL_NON_MARKET_APPS which was used is set to 1 to make the
change transparent to apps who are already querying for this setting's
value.
Test: adb shell am instrument -e class\
'com.android.providers.settings.InstallNonMarketAppsDeprecationTest' -w\
'com.android.providers.setting.test/android.support.test.runner.AndroidJUnitRunner'
Bug: 33947615
Change-Id: Ie38d130bfccd022483a566270fce071acbdb00b7
The settings provider has logic to incrementally reset state
in an effort to recover from pushing a bad value putting the
system in a bad state. The settings provider was not force
persisting its state after a reset so after the reboot we
lost the reset changes. Also while resetting we were also
resetting the package name leading to a promotion of the reset
value to being set by the system. Updated the tests and while at
this added logic to synchronously persist critical settings
such as device provisioned.
Test: All tests pass. Manually tested end-to-end rescue party
bug:34677175
Change-Id: Ib240072df2fa549dae39c301008adf48cdf1573a
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
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
This change adds historical operations to the dump state
of the settings provider. The historica operations are
currently appended only on user-debug and eng builds.
These change is needed to help diagnose the referred
bug and improve the settings provider's maintenance.
bug:30561721
Change-Id: I58a1ba0d598c4d28adcb5e654ebb78cf947e94db
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: I8e0cf7ffa32e86e36e777964eb0c3cc7de02d3c3
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
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
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
