When the home activity launches a non-fullscreen activity as part of
its own task then ensureActivitiesVisibleLocked() must continue past
the launched activity when determining activities to show and hide.
Stopping at the non-fullscreen activity leaves the fullscreen home
activity hidden.
Fixes bug 11555762.
Change-Id: I9058d8cde3a41cb7f9b1f97e5c0cb32e9b0f5af7
One cannot iterate across an entire list if one both removes an entry
and increments the index into the list. Do one or the other or you
will end up with bugs like 11556768 which is now fixed.
Change-Id: I57f1ad13075a005cae3c1cbfae10e230d9af143a
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
...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
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
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
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
setLaunchTime() was only being called from resumeTopActivityLaunched()
but also needed to be called from minimalResumeActivityLocked().
Fixes bug 11104901.
Change-Id: I35c994562dffaf75de014021c775e398224eb3a3
The CL that ensured that a dying task must be in front of the user
(ag/374996) only checked that the task was at the top of /a/ stack,
not on top of the frontmost stack. This checks the stack for being
frontmost before switching to home.
Fixes bug 11208762.
Change-Id: I43f6d380e7a880ec19db03711ada6c7437e15f73
The previous fix that returned to home when a task on top of home was
removed was too broad. If that task was not the foreground task it was
not a good idea to bring the home screen to the front.
Fixes bug 11198552.
Change-Id: I14e5fdc167011f25e0e8490c3e52c5c1dcbffbff
Killing an app that was launched from home was not relaunching home.
Previous situations relaunched the next app (i.e. home) based on the
task flag. However, when an app dies the relaunch is deferred until
the TaskRecord has long been forgotten. This fix rearranges the stacks
immediately upon the TaskRecord being removed from the stack. Then the
next resumeTopActivities() call will start the home task.
Fixes bug 11189555.
Change-Id: I0e09350a7db55ea8b38cce7bf4b69923a6b99494
Screenshots were not being made for tasks with the flag
FLAG_EXCLUDE_FROM_RECENTS set. But if the task is in the foreground
the shot should be taken even with the flag set. This fix adds a test
for tasks being in the foreground.
Fixes bug 11170567.
Change-Id: If42db7f43ed1dd8d2b16b68824adc813b31c94f0
When a dialog has been minimized to recents the windows behind it
won't be visible. Yet we were requiring them to be visible in order to
be included in the ones being restored. This left the background
windows invisible on resume and showed home behind floating dialogs
instead of the activity that launched the dialogs.
Fixes bug 11067724.
Change-Id: Icadd7ec8fe7c73b52982b6ff5b5d98b8fb8476b0
Trying to span all potential stacks looking for apps was too complex
and error-prone. Extending the jb-mr2 method across multiple stacks.
Fixes bug 11080696.
Change-Id: I6391ceae4ad6a0955a409c3fb27472219fd5bf6b
If the last screenshot activity is resumed, we need to always capture
a new screenshot, because it can change at any time.
On the other hand, never create a thumbnail for tasks that have set
themselves to not show on the recent tasks lists, since we have no
use for them.
Change-Id: I38523afc966c125da93339e0100da950119cdf99
Remember which stack was in front when the user changes. Restore that
stack when the user changes back. Remove user state when user is
deleted.
Fixes bug 11068986.
Change-Id: I18dfbc35a0c2e21e7a4024227cbfc5ba1208b3a3
Localize the point where it is determined whether a task should sit on
top of home or return to the task below it.
Fixes bug 11080913.
Change-Id: I79d1ea9722c867d6b550ddfcd1db35517a79cd90
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
- Call in all circumstances but only set launchHomeTaskNext for
focused stack. Previous version didn't call handleAppDiedLocked for
non-focused stack.
- Rearrange logic to run down the top task and make sure that all
remaining activities belong to the dying app. Previous version just
looked at the top non-finishing activity and based its behavior on
that.
Fixes bug 11029560.
Change-Id: Ic3a7c873c4c975577d6b390a8955ff41729bdfde
Fixes jank exposed in 10881705. Specifically background activity
animating up along with translucent activity. Repro steps on manta:
1. From home start Settings.
2. Press home.
3. From home start Downloads (translucent activity that takes 85% of
screen).
4. Observe that as Downloads zooms up the 15% boundary that should be
dimly transparent are showing Settings.
The cause was that there is a finishing activity in the Downloads task
that was used to launch the DownloadsActivity. The existence of that
activity kept the logic from recognizing that the home activity was
behind the DownloadsActivity, not the Settings activity.
This fix descends through all of the activities in a task sitting on
home and makes sure that they only keep home from showing if such
activities are not finishing and visible.
Change-Id: I607afce6b0000b4db634f2ce40a6c37fcee369d7
The home activity was being returned to when any activity in a task
that was launched from home crashed. If there were still activities
left in the task then the crash should have brought up those
activities next, not home.
This may be a partial fix for crashes where the back stack was showing
up under launcher icons. Bug 10858941.
Change-Id: I840a25bd8395bfce46f4e21b112d78b12884706d
If an activity is visible behind the keyguard when it is launched
by another activity then there would be no call to dismissKeyguard.
Because the other activity is pausing the call to dismissKeyguard
is skipped in startActivityLocked(). And because it is already
visible the call to ActivityRecord.windowsVisible() is never made and
the call to reportActivityVisibleLocked() which calls
dismissKeyguard() is also never made.
This change recognizes when an activity is resumed and visible and
calls dismissKeyguard() in that case.
Fixes bug 10732489.
Change-Id: I3de1350a55231aaa14dadc8709fd0fcf4960742c
Back out changes from CLs ag/363992 and ag/363859. These introduced
the bugs found in bug 10917435 which is now fixed. Note that backing
out these changes reintroduces bug 10732489.
Change-Id: Ic5105dd4cfc8bf79c6f06188283d1ee3680c370c
The previous fix for keeping activities from running on startup,
ag/363992, was keeping the home task from launching when the
keyguard should have allowed it.
This fix permits the home activity to launch in such situations.
Fixes bug 10916877.
Change-Id: I429f0d5a13e06a247b9b6b7241f9a3514044c371
Following boot the initial activity was automatically resumed even if
a lockscreen is obscuring it. Refer to CL 363859 for why this breaks
things.
This fix pauses all activities the first time a lockscreen appears.
Completes the fix for bug 10732489.
Change-Id: I6fcac14b574c495aa0e16d798cddc1263c6b4c25
When transitioning from activity-over-launcher to task-over-launcher
ensureActivitiesVisibleLocked() was too aggressive in showing the
launcher. If there were any non-fullscreen activities in a task that
sits over the launcher then the launcher would be shown.
This fix adds a test to make sure the launcher will only be shown if
the bottommost activity in such a task is non-fullscreen.
Fixes bug 10840919.
Change-Id: I5dcd63be3fa2865ae38cbb921332937dfa4b5d47
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
The idea of multiple processes serving as home was unfeasible.
- Revert "Allow for more than one home app." commit
e428a7f662.
- Assign ActivityManagerService.mHomeProcess to the process of the
root activity of the home task.
Addresses bug 10342471.
Change-Id: Ifb494626107d24de1306e320a18206d5b176a7c0
The variable ActivityRecord.mLaunchHomeTaskNext was used to indicate
that the home task should be launched when the activity completed.
This only mattered when it was at the end of a task. As the activity
launched other activities within the same task it needed to be
migrated from activity to activity and task to task. This became
too complicated and was at the wrong level to begin with.
By moving the flag to TaskRecord.mOnTopOfHome the logic is simpler
and the results more predictable.
Fixes bug 10602256.
Change-Id: If0b752522b77be9918f1dba221d0ff670fc01af8
Add a test for emptiness before accessing either mTaskHistory[0] or
TaskRecord.mActivities[0]. This will keep us from hitting
IndexOutOfBoundsException.
Fixes bug 10789624.
Change-Id: If726df888a2c8b393788793b6220a6bffe2df883
Because recents sits on the same stack as launcher it can sometimes be
above launcher. When we were launching home activity because the flag
told us to we would sometimes launch recents instead. This fix makes
sure that the home activity is on the top when it is supposed to be
launched next.
Previously this was fixed by having recents move itself to the back
of the stack after it launched an activity (b/9750207 and ag/336019).
But that solution caused the AppTransition to be set to
TRANSIT_TASK_TO_BACK which left the SOFT_INPUT_IS_FORWARD_NAVIGATION
flag unset. This in turn caused IMEs to remain unlaunched when
returning from recents (b/10240567).
Fixes bug 10240567.
Change-Id: I35c6619af0e68d0e6d9ab87cad06ea7c27e11e27
