Optimize attaching process for starting activity

Originally, any process start will need to go through entire
hierarchy, also, the ensureActivitiesVisible will be called if
an attaching process cannot match any activity. There can be
2 conditions:
1. The find-condition is not accurate enough, which misses the
   launching activity. Then the ensure-visible might refresh
   the latest visibility state and still launch the activity.
2. The attaching process doesn't contain activities, such as
   a pure receiver/service/provider process. Then the invocation
   is redundant and wasteful. Sometimes it may even make some
   noise to transition such as changing visibility randomly by
   unrelated process.

By storing the activities that are required to start process, it
can simply check a small list to know if the attaching process is
started for an activity. This can reduce 97% executing time of
attachApplication if the process is unrelated to activity.

Also ensureActivitiesVisible is no longer needed to catch the
missed cases by traversal. Because the starting activities are
known explicitly.

This also reduces twice duplicated request of process start from
completePause's resumeTop and ensureActivitiesVisible (it will have
extra invocations until ProcessList#startProcessLocked that checks
app.isPendingStart() to ignore). Because the pending records can
be found in startProcessAsync.

This also handles a corner case that if a process is never attached,
the launching app won't stuck on screen with a starting window. The
activity can run a close transition when receiving onProcessRemoved.
Originally it will be stuck because AMS only removes the process when
the start timeout is reached, there won't be a signal about process
died because it was not attached.

Bug: 297502610
Test: atest RootWindowContainerTests#testAttachApplication

Change-Id: I5e88f878eb35b9f5c0d385a3f85564255bd22445

0 files changed, 0 insertions, 0 deletions