...the repeated hour in DST transition
Record the last crash info that caused an app to be marked as a bad app.
Also for the battery work, add a system property tuning parameter to be
able to control the background service start delay, so we can easily
run experiments with it turned off if we want.
Change-Id: Ic33dc464d8011c918a39b912da09ea4f0fb28874
Previously inserted requirment that an activity be visible in order to
block visibility of the home screen is removed.
Fixes bug 11515761.
Change-Id: Ia47cfb4a0b6d90bbbca2b42e12a6048b1644d7cb
Actually, the state representation seems fine, but there was a problem
we are now hitting where the restart interval could get reset back to
0 when it shouldn't be. Also tune the restart parameters a bit.
Change-Id: I364f38e52f5387b2ec3f81009ccc78976ff48891
...not to work on KitKat (was: Janky exit animation)
Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes. In fact, we
were no longer marking "client activity" processes at all.
In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section. This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes. However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.
The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more. There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things. The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.
Finally, note there is some commented out code of a new way to manage
the LRU movement. This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.
Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
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
Minor changes for dumping stack traces:
- Print the native traces right after foreground/persistent apps
- Also include mediaserver, sdcard, and surfaceflinger in traces
Bug: 11321322
Change-Id: Ic09b7da316a5f197dda0ac3bde06f75574cc2166
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
