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
(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)
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:8c2d2c6fc91c6b80809a91ac510667af24d2cf17)
Merged-In: Id95ed43b9cc2208090064392bcd5dc012710af93
Change-Id: Id95ed43b9cc2208090064392bcd5dc012710af93
2 files changed
