summaryrefslogtreecommitdiff
path: root/docs/html/sdk/api_diff/21/changes
diff options
context:
space:
mode:
authorWinson Chung <winsonc@google.com>2017-03-10 08:59:25 -0800
committerWinson Chung <winsonc@google.com>2017-03-10 10:26:52 -0800
commit7900beee54d5dd8d5a057c0bd7bef0c2dcf2d599 (patch)
tree2ed811f69b0fce91019a789c7d8cc62912e40435 /docs/html/sdk/api_diff/21/changes
parent1f1416e51ae676af1a7f2a7a7151be12762b13d4 (diff)
Fixing issue with TaskRecord lookup.
- In ag/1721556, we switched from looking up the task in WM to looking up the task in AM (and using the window container controller). However, AM's call, anyTaskForIdLocked(), will return tasks in the recent tasks list along with the current stacks. The naming of the parameter restoreFromRecents is partly to blame as it does not prevent lookup in the recent tasks and only prevents that task from being restored into the provided stack. As a result, when we removed a task from a stack, we also remove the associated window container controller, but when we query for the task to make a WCC call to it, it finds the one in the recent tasks list and happily uses that one (which crashes because we've the WCC). Instead, we break up the call to explicitly search for tasks in the stacks only, in stacks or recents, and in stacks or recents with restore. All existing calls to anyTaskForIdLocked() that are actually looking up a task for a WCC call (like those in ag/1721556) can use STACK_ONLY, while existing calls will match recents tasks and restore as required. Bug: 35960163 Test: Open up settings > display > brightness dialog, quick switch to another task using overview Change-Id: I835116fa80d47450da8c4de41fe0d54fc70cb43b Signed-off-by: Winson Chung <winsonc@google.com>
Diffstat (limited to 'docs/html/sdk/api_diff/21/changes')
0 files changed, 0 insertions, 0 deletions