Skip to content
Commit eb1936cb authored by Svetoslav Ganov's avatar Svetoslav Ganov
Browse files

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
parent 80376a98
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment