Activities launch starting windows before they are resumed. If another
activity is started after a first activity has launched its starting
window then it was possible that the starting window will never be
removed. An earlier fix, ag/368411, solved this by posting a delayed
message that would remove orphaned starting windows after 10 seconds.
This fix immediately removes starting windows that have been orphaned
through the above sequence.
A few code cleanups are also included in this CL.
Fixes bug 11029212.
Change-Id: I7a9befca92888aefe4000b90716c57c2aa572634
The startService() and stopServie() calls had a redundant check for
the incoming user ID being valid, but with its own custom implementation
that doesn't match the normal handleIncomingUser flow. In fact, for
both of these we are going to do handleIncomingUser anyway when we get
to retrieveServiceLocked(), so there was just no need for this.
Change-Id: I14409a03781a14a5f1a786aceb31dcc77efb062c
The effects of the flag, Intent.FLAG_ACTIVITY_TASK_ON_HOME was being
overwritten by the call immediately after it was set. Changing the
order of operations leaves the effect intact.
Fixes bug 11376962.
Change-Id: I27371e0efeb0c08d1e14514a9e3a63157f6d34d8
When a non-fullscreen task over home launches another non-fullscreen
task then the home task might not be displayed. Looking all the way
down the task stacks until reaching a visible, fullscreen activity or
home provides the right information.
Fixes bug 11273803.
Change-Id: I8dab0956c1cda06ddb7850ea3ffac7f6a223c6ad
The android package is now a special case, not being added to the package list
when creating a multi-process component. There is no need, since this package
is actually the framework itself which must be loaded in every process.
Also cleaned up some of the procstats dump output to help see what is going
on here.
Change-Id: If65d35ecd562f3154bdebfded69c454af6ce8c96
When finishing or stopping an activity the code was automatically
refocusing to the next activity on the same stack independent of the
task's onTopOfHome flag. When the activity eventually finished or
stopped it would then honor the onTopOfHome flag.
This fix examines the onTopOfHome flag and arranges the focus
correctly if home is the next activity to run.
Fixes bug 11318263.
Change-Id: I73a8f5e82de04b01acaffe366b085f9e475e1451
There were circumstances where mFocusedStack could be assigned the
home stack. If this were ever to occur then all subsequent tasks would
be put on the home stack. This fix ensures that there is no way that
mFocusedStack will ever be assigned to the home task.
Fixes bug 11271189.
Change-Id: I7ddd9b6bcbf2787cbe2f44b461ad057ae2241f00
The possibility existed that an activity was set to a task that it was
already being set to. If that were to happen, and it was the only
activity in the only task of the stack the stack would be deleted.
This fixes that situation and logs it as well to confirm that it does
fix bug 11272935. Logging to be deleted upon successful monkey run
exhibiting the log.
Change-Id: I436fdcc9a3734adad81d3ef90f29b93b3ac4dfcd
Two problems addressed here:
- If a call to startActivity() comes in on an activity that is finishing, we can
end up putting the new activity in a stack that isn't actually in use any more
(if the finishing activity is the last one on that stack). This is a bad case,
anyway, so if this happen the treat it as not being called on an existing
activity and switch to NEW_TASK to find a task for it.
- There was a bug in handling PACKAGE_CHANGE broadcasts that would result in the
app's processes being killed, even though the cleanup through the activities
was done. This could leave the activity stack in a bad state. Fix this to
correctly provide an app id for the changing package so that its processes are
killed.
Change-Id: Iece04e0cf95025c3d30353d68bf3d14fd39d44c3
