diff options
| author | Michal Karpinski <mkarpinski@google.com> | 2019-02-05 17:31:50 +0000 |
|---|---|---|
| committer | Michal Karpinski <mkarpinski@google.com> | 2019-02-06 17:55:58 +0000 |
| commit | 9cbb20b73f1accb267a311817a97c39ae1369e2d (patch) | |
| tree | 9525a0e0865b08c06b61b2902a6f76f5a8747bf4 /tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp | |
| parent | 79282ebc9c774fcc90b18cc088aaeadcb7dc0e2e (diff) | |
Fix bugs for background activity starts from notifications
We were facing a few fundamental issues due to trampolines
from PendingIntents.
1) Temporarily whitelist processes of receivers kicked off with
performReceiveLocked() to start background activities too. Previously
we only whitelisted those going through
processCurBroadcastLocked()/finishReceiverLocked() pair.
2) If an activity is being started from PendingIntent, caller
object is not passed in, as the PendingIntent creator's process
might not be alive. In that case we make an effort to retrieve
the caller object for the PendingIntent sender, to make a decision
whether to open the activity based on its foreground/whitelisted
state.
3) Whitelist processes for services also in the cases where the
process isn't alive yet - previously we were only whitelisting if
the process was up, which might often not be the case for trampolines
from notifications. Now we also whitelist the processes that were
brought up explicitly to start the service in question.
Bug: 123404215
Bug: 123677969
Bug: 123688728
Bug: 110956953
Test: atest WmTests:ActivityStarterTests
Test: manual with the citymapper notification that caused the bug
Test: manual with dynamite notifications after killing dynamite
process
Change-Id: I2ddc6701dde064177ff47a9c43efc0c118565ce2
Diffstat (limited to 'tests/DynamicCodeLoggerIntegrationTests/src/cpp/test_executable.cpp')
0 files changed, 0 insertions, 0 deletions