summaryrefslogtreecommitdiff
path: root/libs/androidfw/AttributeResolution.cpp
diff options
context:
space:
mode:
author Riddle Hsu <riddlehsu@google.com> 2023-10-03 14:19:38 +0000
committer Riddle Hsu <riddlehsu@google.com> 2023-10-05 13:28:11 +0000
commit8f42ef5660bbc7cef1cb635dfe1fb9f1eb98680e (patch)
tree3ee1a624c61f8b2412ba9a732662069c5e9f893c /libs/androidfw/AttributeResolution.cpp
parent6c29a6fb047c2426201e7bc855afd9ba6526607a (diff)
Update visibility when visible activity crashed
Previously, if a top fullscreen app is crashed when a display transition is collecting, the transition will be ready and sent directly from finishTopCrashedActivityLocked -> finishIfPossible -> continueWindowLayout -> BLASTSyncEngine.SyncGroup#tryFinish. That causes the transition to contain a change to hide display area because nothing is visible in it. Now finishTopCrashedActivities has similar steps as handleAppDied. If there is perceptible activity in the crashed process, the next top activity will be requested to visible at the same time. Then the transition can recognize that the display area is visible. Note that finishTopCrashedActivityLocked calls finishIfPossible, so it may already adjust focusable task. But because the crashing activity is pausing (pause->resume from switch display and then resume -> pausing when finishing for crash), the next activity won't resume until the pausing is gone. Then it requires ensureActivitiesVisible to make the current top activity (its task was moved to front when adjusting focusable task) visible. Bug: 300790517 Test: RootWindowContainerTests#testRemovingRootTaskOnAppCrash Change-Id: I935121ed53638720ec3c8ef872f7c78e90edd714
Diffstat (limited to 'libs/androidfw/AttributeResolution.cpp')
0 files changed, 0 insertions, 0 deletions