| 97e5130234bcdc1c4a705be4e548302934499bd4 |
|
16-Aug-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Properly compute default and system set flag on an upgrade
We added the notions of a default value and whether this default is set
by the system for a setting which is needed for experiments since in
case a bad value is pushed we should be able to incrementally rollback
to a stable state. If a system component sets a setting value this
automatically becomes the default. System components are the platform
package, the special UIDs (telephony, etc), apps singed with the
platform cert, system installed persistent apps, and SUW.
In N we did not have the notion of a default and during an upgrade need
to adjust the default and whether this default is set by the system.
This migration runs as the system UID and was incorrectly computing that
the package that changed the settings last was a part of the system and
setting the current value as its default set by the system. This
resulted in taking more storage space as we also count the default which
led the package which changed the setting to go over the quota and that
throws. If the first caller into the settings provider is the system
main
thread (almost certain) we end up throwing an exception on the system
main thread - crashing the system server.
Test: flash N, install an app abusing sys settings, update to O
Merged-In:I8e2c578cb564b2bc2de7c793eb40dea2639fa04e
bug:64718888
Change-Id: I82f0d52fd7984fb2d0da1fd91399a0c914dfa24b
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| e83df48908a1c83056f6be2d6d4a623a3c3bbd2a |
|
09-Mar-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Avoid cross lock acquisition leading to deadlocks
Test: manual
bug:36007738
Change-Id: I3db09af07857435682754916849433a809547974
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 480b570603df7c7b63372483923239f57a1468b4 |
|
03-Mar-2017 |
Svet Ganov <svetoslavganov@google.com> |
Add a missing write lock to settings state.
Atomic file requires sync between writers otherwise we may end
up with partially written settings file and no backup to recover.
Test: not testable by how we hold a mutex
bug:35915719
Change-Id: I97eebf869fa7e4989dcd2a29e4418c22706edcb8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 5fb405ba60dc6daca54d507909b68b5ad8144920 |
|
27-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Ensure settings provider joins the rescue party
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| d72c39709d2f0a850dc32544324bfe4729ce81c6 |
|
28-Dec-2016 |
Eugene Susla <eugenesusla@google.com> |
Add ability to dump settings as proto buf
Test: Extracted the result via proto bug and as text and compared,
ran new CTS Setting incident test
Change-Id: Icf7b54b9c5c0a613dfd413ad575001c7b637ca01
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.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/src/com/android/providers/settings/SettingsState.java
|
| 32f40ee1a2d4185282543efe8db709e779ea2f63 |
|
21-Oct-2016 |
Dianne Hackborn <hackbod@google.com> |
Implement Binder shell command for settings provider.
The provider now published a system service, through which you
can do direct shell commands. The commands are a copy of what
the existing "settings" command does (in a follow-up, that will
be converted to a simple script that calls this).
Also improved a few things in the provider:
- Don't allow implicit creation of settings data for users that
don't exist.
- Improve dump to include the package name that applied each setting
and remove misleading stuff from historical data (and this is now
available through "dumpsys settings" instead of the provider dump).
Test: manual
Change-Id: Id9aaeddc76cca4629d04cbdcbba6a311e942dfa6
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 6ad9366b747c4111f3289b14e8daef42bb76cd68 |
|
04-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add historical logging to settings provider am: a340bfd7a1
am: ba92753043
Change-Id: Ic365c69b2bb76dff17dd6c8b932f017c27c53d4f
|
| a340bfd7a1e639bb50125a62cfb1a14e2565607e |
|
03-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add historical logging to settings provider
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 1db5c20960c2b56f7864adece4ecc17465252e5f |
|
16-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Use the correct handler when persisting the settings state." into nyc-dev am: 967fcfa593
am: 23d729deb8
* commit '23d729deb8d78d5806dec60453174ccfa28b843d':
Use the correct handler when persisting the settings state.
Change-Id: I1e6002fd970f9eda095a6c1c17f09937cee67aaf
|
| 9205749cfe9c36fb740bb067805351fb8abf9c8f |
|
16-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Use the correct handler when persisting the settings state.
bug:28784358
Change-Id: Iba9d569bae67c7ba0c3ab0a486ae14efa84a7acf
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 21914ba1aeadea9b7748c2a1b594fb4cad1e72ae |
|
12-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Merge "Persist settings on a dedicated background thread" into nyc-dev
am: 00749aeb15
* commit '00749aeb15d52151fcc9f9051b525840c49e14ce':
Persist settings on a dedicated background thread
Change-Id: I31ec418fb5b1338bc8d55eec08568028d42d95a2
|
| a8f9026d22dae7fcb385bd06ed475a5dd36993c3 |
|
10-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Persist settings on a dedicated background thread
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
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 8de4d5eccacfb220442226b886a4b649a9f1063d |
|
10-May-2016 |
Guang Zhu <guangzhu@google.com> |
Merge "Revert "Persist settings on a dedicated background thread"" into nyc-dev
am: 875e99443f
* commit '875e99443f6c56d71090b8bedddd71f2b9601787':
Revert "Persist settings on a dedicated background thread"
Change-Id: If082c93a5868b2a95965458a2c06defe101edd72
|
| 5537ce1f94ef1851d316ecf029e13ef7833f6c3a |
|
10-May-2016 |
Guang Zhu <guangzhu@google.com> |
Revert "Persist settings on a dedicated background thread"
Bug: 25472484
This reverts commit 82b8c92b97d3c7006d7a9f67a9cdb83263d6bf2c.
Change-Id: I1a8c2e186ad74d78f1c82fe508c6f71c438177dc
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| f528fb457bbec504ba9e8f6b779fa70f6f37cb58 |
|
10-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Persist settings on a dedicated background thread
am: 82b8c92b97
* commit '82b8c92b97d3c7006d7a9f67a9cdb83263d6bf2c':
Persist settings on a dedicated background thread
Change-Id: I596e8f3ee73b886c79f2b79d47c73111e5f2d0a3
|
| 82b8c92b97d3c7006d7a9f67a9cdb83263d6bf2c |
|
09-May-2016 |
Svet Ganov <svetoslavganov@google.com> |
Persist settings on a dedicated background thread
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: Icf38e72403b190a8fa9d0554b8dd83ce78da3bc8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 469ae415015085d00537306e3967d96fab4a635f |
|
27-Apr-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Add a missing null object check" into nyc-dev
am: 44cc663
* commit '44cc663f7873e37ee6bf19a01c0b404316e180fc':
Add a missing null object check
Change-Id: I7d102a0bd250eeb11e969295576217fa1d7beb45
|
| 83a1f7fe91816959715067987dd7f4727492f129 |
|
27-Apr-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add a missing null object check
We now have a null object instead of null values and
there was a place where we returned null instead of
the correct null object.
bug:28423485
Change-Id: I2626768acdf8d19fc94aa5e978eb057818450fa5
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| d4bc15b66be44af031f5e78574781b8f21923404 |
|
26-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Merge "Ensure local settings caches are not stale" into nyc-dev
am: f71d7fe
* commit 'f71d7feef22db9e0cab2f32edc7440aedb86fdfe':
Ensure local settings caches are not stale
Change-Id: I356b9ad0b6dc1e91bfad140de1b9fc79ab6efef3
|
| 53a441ca8eda5a3e6209a952b1bbd32a39e19a1c |
|
20-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Ensure local settings caches are not stale
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 28532d00267c73b8e0fa5235169fa72c414e1cd0 |
|
21-Apr-2016 |
Tobias Thierer <tobiast@google.com> |
frameworks/base: Avoid Long object allocations in Long.valueOf()
Replace usages where the Long is immediately unboxed or thrown
away with Long.parseLong().
In TaskRecord.java, I also fixed up similar uses of
{Boolean,Integer}.valueOf()
Tested: built frameworks/base successfully.
Bug: 28289401
(cherry picked from commit 4bd017d6a5437f153b2b0a149a5dde0b85bf6907)
Change-Id: Icfa4708946e774f4a1bacf185c3fd11a7087017e
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 41f3c49cce2505f0e15890bb2c8476e0bf9425a4 |
|
09-Nov-2015 |
Svetoslav <svetoslavganov@google.com> |
Don't crash if cannot persist settings
bug:23569962
Change-Id: I19fd7d37b6de251696d119cfc33e87e9743b2029
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.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/src/com/android/providers/settings/SettingsState.java
|
| 3dcdd37b66bb996ae332c29e25788a118a9e2691 |
|
29-May-2015 |
Svetoslav <svetoslavganov@google.com> |
Use AtomicFile APIs correctly when reading.
21280155
Change-Id: I354ebac8fc91d8f28eec6016474a9521ff2a490d
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 9e9e2e73c6ec7bece20268196dc89ad0c8bafad4 |
|
08-May-2015 |
Wojciech Staszkiewicz <staszkiewicz@google.com> |
Pass charset to XmlPullParser.setInput instead of null
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 8de348095f0967ffaa09d2448dc1ccff72a4e284 |
|
27-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
DO NOT MERGE Do not clean up global/system settings on package unintalls.
Legacy apps can write their own entries in the system settings and
when they get uninstalled these are hanging around forever polluting
the settings table. We keep track of which settings an app added and
when the app is uninstalled we drop its custom entries. The trouble
was that we did the same thing for global and secure settings with
no explicit list of platform defined settings. Hence, if say a test
signed by the platform certificate touches platform defined global
or secure settings and is then uninstalled, we would drop the platform
defined entries portentially crippling the system.
bug:20113160
Change-Id: Ia21694f6326ad4a1795c4666027b366e26c05a23
(cherry picked from commit b128540dc741c424d4f652419686882b7a3bfa06)
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| e723e54650c5ace8beb47bc4d3c493e276e65d91 |
|
23-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Revert some unnecessary changes in handling XML read
Change-Id: I3bbbc3159930d80e2e1f28fa9c0035ae5029d4b8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| ba0821ed3bc2536be02df1ae850619b111cbd6f4 |
|
22-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Make read/write from/to XML persistent state more robust.
When writing critical state to XML an excpetion can lead to creating
a malformed XML that is later parsed and may put the device in a bad
state. Hence, on any error while writing we should bail out and drop
the partially write state on the floor.
Corollary, any error on parsing can lead to having a partially read
state that is not consistent which may lead to writing this bad state
back to disk. Hence, on any error while parsing we should bail as
our current state may be unrecoverable.
Change-Id: Ia050c16198cb583f8a51263ad2035dbb948052b8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| c9755bc4f2183d6d8e035e6a448b2c948dcd3a01 |
|
28-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix a regression in settings parsing
Change-Id: I222bac482a843112ae031b00c83e3765ea6b456c
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 8440ca3934dbb65743b357006e4a019e4351d479 |
|
28-Mar-2015 |
Svet Ganov <svetoslavganov@google.com> |
Relax the parsing code in settings provider.
The practice in the system server is to have lenient parsing code
to avoid the whole system being unusable due to a single XML error.
Change-Id: Idf44031edf5221966f3352ca2f83e284973ab95f
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| e1519582ab3010a132d4c4f1fa5cc92fad7cbc39 |
|
13-Mar-2015 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revert "Persist settings on a normal priority thread."
This reverts commit d289e64a2d7c8efba78b9066b647ee321eba701a.
Change-Id: Ic9455b538e0be8b9a4e4672f99b14978e70d2911
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| d289e64a2d7c8efba78b9066b647ee321eba701a |
|
13-Mar-2015 |
Svetoslav <svetoslavganov@google.com> |
Persist settings on a normal priority thread.
We were doing the work for persisting settings on a background
priority thread and as a result persistence was not happening
correctly on a low end devices. Now we use a worker thread with
normal priority.
bug:19611897
Change-Id: I378c6e324935f5e3def8b986bd48486bfab55265
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 174fa280d106f713e2d742281adfd8166c61e012 |
|
11-Mar-2015 |
Raph Levien <raph@google.com> |
Fix XML parsing crash in SettingsProvider
A previous change added more whitespace to settings_global.xml to
improve human readability, but the parser is overly picky in ignoring
whitespace. This patch makes it accept all whitespace strings.
Bug: 19696812
Change-Id: I3ebb8f6df2e25f4e6b6841da743be3f3a91e2442
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| c3f56c3cb51d486e581c26876e2ae1368f91e2ca |
|
11-Mar-2015 |
Svetoslav <svetoslavganov@google.com> |
Make settings XML files readable
Change-Id: I320f5419e045d257dc5ccbf81a9434f9b9d38564
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.java
|
| 85b880035daf6a9100f5d1b66f4382f6f21497f8 |
|
18-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Merge "Add dump support to the settings provider"
|
| b505ccc90667ad69a1b122f025a415a3b2aee6af |
|
17-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Add dump support to the settings provider
Change-Id: I1338af4c660e3ecc412954a7cb9b820952aae523
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsState.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/src/com/android/providers/settings/SettingsState.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/src/com/android/providers/settings/SettingsState.java
|