diff options
| author | Bernardo Rufino <brufino@google.com> | 2019-08-29 19:12:28 +0100 |
|---|---|---|
| committer | Bernardo Rufino <brufino@google.com> | 2019-09-05 18:58:45 +0100 |
| commit | 39ec0f081e7b6c515c1ac156c3e9a4177c553dce (patch) | |
| tree | 35e70be064ab1eec47f22362ef34355bf6e1b671 /tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp | |
| parent | 4537e61955b50965e4e5121268a7d4cdfd71db12 (diff) | |
Don't consider tasks with INITIALIZING top activity as visible
To fix b/130645908, tasks with top activities in INITIALIZING state were
considered visible. This allowed apps to circumvent background activity
launch restriction by starting 2 activities when in a background stack.
The first activity will remain in INITIALIZING state (since it's in the
bg), so the second launch is permitted since top activity is
INITIALIZING.
Removing '|| topActivity.isState(INITIALIZING)' removes the
vulnerability and curiously still allow the legitimate use case of the
bug linked above to work, i.e. the test in ag/7088262 still passes. This
is because of 2 reasons:
1) Grace period introduced in ag/7638265.
2) Allow bg activity starts to put activity on top of bg task (instead of
fg’ing it) in ag/7190176.
I verified (2) by removing the grace period check, reverting the linked
CL and verifying that the test failed.
This essentially reverts ag/7090415.
Test: atest BackgroundActivityLaunchTest \
RootWindowContainerTests \
WmTests:ActivityStarterTests \
CtsWindowManagerDeviceTestCases:ActivityStarterTests
Bug: 138583650
Bug: 130645908
Change-Id: Iee4ba841c6c83888b55c5cb55fffc949048d2030
Diffstat (limited to 'tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp')
0 files changed, 0 insertions, 0 deletions