Skip to content
Commit f7654c58 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

bug:64718888

Change-Id: I24f36ed46bb97e03f72d04ecd9e7ca53da7588c4
parent 34c949d2
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