)]}'
{
  "commit": "861a44baf3001e98febe2598bf7cbf3818455040",
  "tree": "002d33bc3018479da2744901889dde306e8e5863",
  "parents": [
    "70484ee7bc7e6f210c4e90bbe0df18b1a9d68fac"
  ],
  "author": {
    "name": "Josh Tsuji",
    "email": "tsuji@google.com",
    "time": "Mon Sep 11 17:23:11 2023 -0400"
  },
  "committer": {
    "name": "Josh Tsuji",
    "email": "tsuji@google.com",
    "time": "Tue Sep 12 13:32:49 2023 -0400"
  },
  "message": "Ensure the keyguard is force-shown after a power off/on during unlock.\n\nThis fixes b/298450484, where unlocking an insecure keyguard and then near-instantly pressing the power button twice results in showing the lockscreen over the app/launcher. The race condition requires the device to be turned off and then back on within the time it takes the asynchronous startKeyguardExitAnimation call to return. This is easiest to reproduce if the double-tap camera launch gesture is disabled.\n\nThis bug was introduced by ag/24548147, which fixed a regression where the device would remain unlocked indefinitely after locking during unlock from the bouncer. That fix worked by checking isInteractive() and refusing to (incorrectly) set the keyguard to unlocked if the device was going back to sleep during an unlock.\n\nUnfortunately, this CL\u0027s bug is caused by the fact that the keyguard is (correctly) not set to unlocked when it\u0027s locked during unlock. We have code that notices if the keyguard states don\u0027t match, and forces a call to setShowing(force\u003dtrue) to rationalize these states. In this case, the fix resulted in us thinking that we were correctly already showing the keyguard. We actually are showing the keyguard UI, but we needed to tell WM again since the keyguardGoingAway call resulted in WM showing the app/launcher surface.\n\nThis CL keeps the fix from ag/24548147, and adds three additional checks that in theory, only skip short-circuit code and force the correct keyguard state:\n- in doKeyguardLocked, refuse to short-circuit if the keyguard is going away. This makes sense - going away is being cancelled if we\u0027re \"doing\" the keyguard (showing it).\n- in handleShow, force setShowingLocked if mHiding\u003dtrue (the previous condition) OR if we\u0027re going away. mHiding is actually only true between the initial call to keyguardGoingAway, and the return of the async startKeyguardExitAnimation call. During the going away animation, mHiding is false, so we don\u0027t force setShowingLocked if we re-show the keyguard during that time.\n- in exitKeyguardAndFinishSurfaceBehindRemoteAnimation, add to the ag/24548147 fix by also refusing to finish unlocking if mPendingLock \u003d true. In the bug case, pressing power twice very quickly can result in isInteractive being true (since the screen turned back on), while a lock is still pending from the first power button press. If we\u0027re about to lock the keyguard again, it makes sense to not finish exiting the keyguard.\n\nThis is, as usual, as safe a fix as they come (we\u0027re forcing setting the correct state), but of course, that\u0027s what ag/24548147 did.\n\nFixes: 298450484\nTest: disable camera gesture AND quintuple tap to call 911, set security to swipe mode, long-press lock icon and instantly double tap power as quickly as you can\nTest: unlock from bouncer to an app, sleep during app launch animation, verify device locks\nChange-Id: I02a25859eec3a7fb853001463dacb3730feb9c1d\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ab294a6579fe14bbdea7f5a440ff6af84c8ed605",
      "old_mode": 33188,
      "old_path": "packages/SystemUI/src/com/android/systemui/keyguard/KeyguardViewMediator.java",
      "new_id": "bf0d8adaeb9690b41b106f9932574944cd3c9f47",
      "new_mode": 33188,
      "new_path": "packages/SystemUI/src/com/android/systemui/keyguard/KeyguardViewMediator.java"
    }
  ]
}