tree 3a81683832a2e1d75d06598e3e0b86548747fb0d
parent e8f3cba739276df54536e5f5cbfc36fb12388bab
author Svetoslav Ganov <svetoslavganov@google.com> 1502920200 -0700
committer The Android Automerger <android-build@android.com> 1502998103 -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

Merged-In:I8e2c578cb564b2bc2de7c793eb40dea2639fa04e

bug:64718888

Change-Id: I82f0d52fd7984fb2d0da1fd91399a0c914dfa24b