summaryrefslogtreecommitdiff
path: root/libs/androidfw/ResourceTimer.cpp
diff options
context:
space:
mode:
author Matt Pietal <mpietal@google.com> 2022-08-18 12:04:43 +0000
committer Matt Pietal <mpietal@google.com> 2022-09-15 11:48:17 +0000
commitc27cf661a6b14849bd13ba69b5ee40c9066fcf2c (patch)
treec8cb4097933f2ad5368d439592ab9b82a7a9578f /libs/androidfw/ResourceTimer.cpp
parentf8f07e22f1ba2b3c19a22a4c69aeb7953a36c4b6 (diff)
[DO NOT MERGE] Do not dismiss keyguard after SIM PUK unlock
After PUK unlock, multiple calls to KeyguardSecurityContainerController#dismiss() were being called from the KeyguardSimPukViewController, which begins the transition to the next security screen, if any. At the same time, other parts of the system, also listening to SIM events, recognize the PUK unlock and call KeyguardSecurityContainer#showSecurityScreen, which updates which security method comes next. After boot, this should be one of PIN, Password, Pattern, assuming they have a security method. If one of the first dismiss() calls comes AFTER the security method changes, this is incorrectly recognized by the code as a successful PIN/pattern/password unlock. This causes the keyguard to be marked as done, causing screen flickers and incorrect system state. The solution: every call to dismiss() should include a new parameter for the security method used. If there is a difference between this parameter and the current value in KeyguardSecurityContainerCallback, ignore the request, as the system state has changed. Bug: 218500036 Test: atest KeyguardSecurityContainerTest Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243 Change-Id: I30226bc7b5eda9480d471b35fe81e106b0491ff8
Diffstat (limited to 'libs/androidfw/ResourceTimer.cpp')
0 files changed, 0 insertions, 0 deletions