| 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/SettingsService.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/SettingsService.java
|
| 0b1501a7c8965236e93bd47b45d5dfc0767d5c41 |
|
05-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Warn makeDefault ignored for system settings only if true
Test: changed system setting and got it back without a warning
bug:33816118
Change-Id: I4e185b46467fc885d2bafedbcbdf41354d0fa9d8
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsService.java
|
| ce7daaf982f6848fd4f88c3cbbcd63ed2a5a897f |
|
28-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fix settings shell command
Test: run shell commands and verified result
Change-Id: I24e87a0efa9330a5872d300e17083d320fcc0573
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsService.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/SettingsService.java
|
| ea93fe75396465b26429cfe1c1dcfadf7351354f |
|
02-Dec-2016 |
Steve McKay <smckay@google.com> |
Replace ContentProvider SQL args w/ Bundle & Constants.
Test: cts-tradefed run cts-dev -m CtsContentTestCases
Bug: 30927484
Change-Id: Idb9dbc2b80896e9f8474a0db71353b7a3810d597
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsService.java
|
| dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 |
|
11-Nov-2016 |
Sudheer Shanka <sudheersai@google.com> |
Update usage of ActivityManagerNative.
- Remove references to ActivityManagerProxy.
- Add isSystemReady to ActivityManager.
Bug: 30977067
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts
adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/SettingsService.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/SettingsService.java
|