summaryrefslogtreecommitdiff
path: root/libs/input/PointerController.cpp
diff options
context:
space:
mode:
author Eric Biggers <ebiggers@google.com> 2023-02-17 17:50:34 +0000
committer Eric Biggers <ebiggers@google.com> 2023-02-22 17:08:11 +0000
commitc89db6f3727f8ca8b2a756eab1e19bb28d04f591 (patch)
treedaa73dd55282fc1bee11d217e42a9555b78399b4 /libs/input/PointerController.cpp
parent8128beb12a6dea98700321a716d7e64105df6536 (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