tree 51a377ef9d5080b28ee0f1b4fd836e29c16ae011
parent 34c949d2dc2d653070e3b58166cd9083d91639e7
author Svetoslav Ganov <svetoslavganov@google.com> 1502930002 -0700
committer Svetoslav Ganov <svetoslavganov@google.com> 1502930020 -0700

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

bug:64718888

Change-Id: I24f36ed46bb97e03f72d04ecd9e7ca53da7588c4