tree f8541cf3b9891a9ec2eb62dc25b342b2ffc534d8
parent 331b8156c7a788dab6fdd9c97f1b3bf6f5298005
author Svet Ganov <svetoslavganov@google.com> 1478550246 -0800
committer Svetoslav Ganov <svetoslavganov@google.com> 1482267909 -0800

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