diff options
| author | 2023-02-17 17:50:34 +0000 | |
|---|---|---|
| committer | 2023-02-22 17:08:11 +0000 | |
| commit | c89db6f3727f8ca8b2a756eab1e19bb28d04f591 (patch) | |
| tree | daa73dd55282fc1bee11d217e42a9555b78399b4 /libs/input/PointerController.cpp | |
| parent | 8128beb12a6dea98700321a716d7e64105df6536 (diff) | |
Don't allow LOCK_PATTERN_* settings to be read with no permission
Eliminate the exception for the three LOCK_PATTERN_* settings in
LockSettingsService.checkDatabaseReadPermission().
To do this, make the public API android.provider.Settings.Secure stop
calling ILockSettings.getString() for these settings for apps targeting
a pre-M API level. Instead, just always return "0".
This should be very safe, since not only have pre-M target API levels
mostly been phased out, but the only one of these settings that didn't
*already* always return "0" was LOCK_PATTERN_VISIBLE. That one was
unlikely to be used by apps, as it just indicated whether the user had
the "Make pattern visible" preference enabled the last time they had a
pattern; it didn't reliably indicate whether the user actually had a
pattern. Only LOCK_PATTERN_ENABLED is known to have been used by an
app, and that has returned "0" since Android 11 due to commit
a486e2d780b7 (http://ag/10400376) moving the special-case handling of
LOCK_PATTERN_ENABLED into getBoolean() instead of getString().
Finally, remove the special-case handling of LOCK_PATTERN_ENABLED from
getBoolean(), as it's clearly not needed. This change removes the only
potential user, but the code was in the wrong place for it anyway.
Bug: 204903437
Merged-In: If7a47ae9c3834e6a9a14900e86bc5a68c7cbdc97
Change-Id: If7a47ae9c3834e6a9a14900e86bc5a68c7cbdc97
Diffstat (limited to 'libs/input/PointerController.cpp')
0 files changed, 0 insertions, 0 deletions