tree 9525a0e0865b08c06b61b2902a6f76f5a8747bf4
parent 79282ebc9c774fcc90b18cc088aaeadcb7dc0e2e
author Michal Karpinski <mkarpinski@google.com> 1549387910 +0000
committer Michal Karpinski <mkarpinski@google.com> 1549475758 +0000

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