tree af0eab9c7598317384a09b773fb6361a035c32a4
parent f4361774253065eafb54af0cb7750717145758c6
author Eric Biggers <ebiggers@google.com> 1690581783 +0000
committer Eric Biggers <ebiggers@google.com> 1691044561 +0000

RESTRICT AUTOMERGE: SettingsProvider: exclude secure_frp_mode from resets

When RescueParty detects that a system process is crashing frequently,
it tries to recover in various ways, such as by resetting all settings.
Unfortunately, this included resetting the secure_frp_mode setting,
which is the means by which the system keeps track of whether the
Factory Reset Protection (FRP) challenge has been passed yet.  With this
setting reset, some FRP restrictions went away and it became possible to
bypass FRP by setting a new lockscreen credential.

Fix this by excluding secure_frp_mode from resets.

Note: currently this bug isn't reproducible on 'main' due to ag/23727749
disabling much of RescueParty, but that is a temporary change.

Bug: 253043065
Test: With ag/23727749 reverted and with my fix to prevent
      com.android.settings from crashing *not* applied, tried repeatedly
      setting lockscreen credential while in FRP mode, using the
      smartlock setup activity launched by intent via adb.  Verified
      that although RescueParty is still triggered after 5 attempts,
      secure_frp_mode is no longer reset (its value remains "1").
Test: Verified that secure_frp_mode still gets changed from 1 to 0 when
      FRP is passed legitimately.
Test: atest com.android.providers.settings.SettingsProviderTest
Test: atest android.provider.SettingsProviderTest
Change-Id: Id95ed43b9cc2208090064392bcd5dc012710af93
(cherry picked from commit 9890dd7f15c091f7d1a09e4fddb9f85d32015955)
(changed Global.SECURE_FRP_MODE to Secure.SECURE_FRP_MODE,
 needed because this setting was moved in U)
(removed static keyword from shouldExcludeSettingFromReset(),
 needed for compatibility with Java 15 and earlier)
(resolved conflict in resetSettingsLocked())
Merged-In: Id95ed43b9cc2208090064392bcd5dc012710af93