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
|
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
|
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
|
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
|
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
|