I discovered a bug but I don't know exactly where it is because it's affecting multiple locations.
but the main one is the device's alarm when you touch the lock screen, in the standard deskclock it completely ignores the qs blocking by displaying the list of qs notifications allowing modification of the parameters, in addition it does not allow the gesture of swiping to any side making it impossible to deactivate in a normal way, and another bug that causes this is in the recents because on the home screen when you remove the alarm, when you in the recents move to the end it cannot return by swiping to the right it gets stuck. The following is what I got recently, you can easily test the alarm by setting it to wake up on lock; I would analyze it below
I found evidence of the bug, without changing anything.
The problem appears to be in the Launcher/Quickstep/recents runtime state, not in its tree:
dumpsys activity recents shows a buggy alarm task:
Task #570 com.android.deskclock/.alarms.AlarmActivity nonResizable
This task has two AlarmActivity ActivityRecords within the same task, which is already abnormal.
In the Launcher log, recents goes to Overview, loads the list of tasks, but starts repeating:
CUJ=LAUNCHER_CLOSE_ALL_APPS_SWIPE canceled due to timeout
and also:
CUJ=LAUNCHER_OPEN_ALL_APPS canceled due to timeout
During your attempts, the log only shows TaskbarManager: dispatchTouchEvent and OverviewActionsView updates, but does not show a crash. In other words: the touch arrives in the Launcher, but the recents/gesture state is stuck or inconsistent.
The dumpsys window/input also shows recents_animation_input_consumer still present while the Launcher is focused. It is NOT_VISIBLE, so it is not possible to say that it is blocking input, but it combines with the animation/recents state to be somewhat stuck.
The strongest point is this: the ActivityManager still has the buggy alarm task, but in the Launcher's applyLoadPlan it does not normally appear in the loaded list. This seems like a mismatch between the system's real task and Quickstep's internal model after the bugged alarm.
Conclusion: it doesn't look like a device tree, sepolicy, kernel or overlay bug. Looks like broken Launcher/Quickstep state caused by non-resizable fullscreen alarm/task. I didn't fix the runtime because you asked just to find the bug.
18:27
and correction in deskclock only?
18:33
Probably not “DeskClock only”.
From the log, the trigger came from DeskClock/AlarmActivity, but what got bugged was the status of Launcher3Quickstep/recents. The real fix might be in one of these places:
DeskClock: if it is creating/duplicating fullscreen AlarmActivity in the same task in the wrong way. This would explain the two ActivityRecord in task #570.
Launcher3/Quickstep: if recents does not handle a duplicate nonResizable/fullscreen alarm task well and stops the scroll/gesture at the end of the list.
ActivityTaskManager/WindowManager framework: less likely, but possible if it leaves the fullscreen alarm task in an inconsistent state after dismiss/snooze.
I wouldn't touch your tree for that. First I would isolate it like this: play the alarm, capture dumpsys activity recents before/after, and see if the duplicate of AlarmActivity always appears. If it appears, it starts with DeskClock. If the duplicate task is “valid” but only recents crashes, then it is Quickstep.
I discovered a bug but I don't know exactly where it is because it's affecting multiple locations.
but the main one is the device's alarm when you touch the lock screen, in the standard deskclock it completely ignores the qs blocking by displaying the list of qs notifications allowing modification of the parameters, in addition it does not allow the gesture of swiping to any side making it impossible to deactivate in a normal way, and another bug that causes this is in the recents because on the home screen when you remove the alarm, when you in the recents move to the end it cannot return by swiping to the right it gets stuck. The following is what I got recently, you can easily test the alarm by setting it to wake up on lock; I would analyze it below
I found evidence of the bug, without changing anything.
The problem appears to be in the Launcher/Quickstep/recents runtime state, not in its tree:
dumpsys activity recents shows a buggy alarm task:
Task #570 com.android.deskclock/.alarms.AlarmActivity nonResizable
This task has two AlarmActivity ActivityRecords within the same task, which is already abnormal.
In the Launcher log, recents goes to Overview, loads the list of tasks, but starts repeating:
CUJ=LAUNCHER_CLOSE_ALL_APPS_SWIPE canceled due to timeout
and also:
CUJ=LAUNCHER_OPEN_ALL_APPS canceled due to timeout
During your attempts, the log only shows TaskbarManager: dispatchTouchEvent and OverviewActionsView updates, but does not show a crash. In other words: the touch arrives in the Launcher, but the recents/gesture state is stuck or inconsistent.
The dumpsys window/input also shows recents_animation_input_consumer still present while the Launcher is focused. It is NOT_VISIBLE, so it is not possible to say that it is blocking input, but it combines with the animation/recents state to be somewhat stuck.
The strongest point is this: the ActivityManager still has the buggy alarm task, but in the Launcher's applyLoadPlan it does not normally appear in the loaded list. This seems like a mismatch between the system's real task and Quickstep's internal model after the bugged alarm.
Conclusion: it doesn't look like a device tree, sepolicy, kernel or overlay bug. Looks like broken Launcher/Quickstep state caused by non-resizable fullscreen alarm/task. I didn't fix the runtime because you asked just to find the bug.
18:27
and correction in deskclock only?
18:33
Probably not “DeskClock only”.
From the log, the trigger came from DeskClock/AlarmActivity, but what got bugged was the status of Launcher3Quickstep/recents. The real fix might be in one of these places:
DeskClock: if it is creating/duplicating fullscreen AlarmActivity in the same task in the wrong way. This would explain the two ActivityRecord in task #570.
Launcher3/Quickstep: if recents does not handle a duplicate nonResizable/fullscreen alarm task well and stops the scroll/gesture at the end of the list.
ActivityTaskManager/WindowManager framework: less likely, but possible if it leaves the fullscreen alarm task in an inconsistent state after dismiss/snooze.
I wouldn't touch your tree for that. First I would isolate it like this: play the alarm, capture dumpsys activity recents before/after, and see if the duplicate of AlarmActivity always appears. If it appears, it starts with DeskClock. If the duplicate task is “valid” but only recents crashes, then it is Quickstep.