...ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Don't try to move process records associated with dead service
connections.
Technically we should probably be clearing the binding/service's
app entry so we don't get into this case, but the least intrusive
change for now is this check.
Change-Id: I6683e692eb5a8fa4f8ec1fa31bd63ec3d7f878ef
...activity chooser from being shown
Add more useful output when intent filter debugging is enabled.
Change-Id: I3722b03ed625046398e81233cf7fb6aa5ded5eca
TLDR: Having a resumed activity behind keyguard can cause the keyguard
not to be dismissed.
Swiping the home button to launch Google Now causes an ASSIST intent
to be launched. The ASSIST intent starts SearchActivity which then
launches GEL. If an activity is resumed behind the keyguard when this
happens then that activity will be paused.
Because that activity is PAUSING, ActivityStackSupervisor
startActivityLocked() doesn't call dismissKeyguard() immediately.
Instead dismissKeyguard will be called later when GEL switches from
not-visible to visible. However, if the paused activity happens to be
GEL then there is never a not-visible to visible transition and
dismissKeyguard never gets called.
This fix removes an unnecessary call to resumeTopActivitiesLocked
which was causing activities behind the lockscreen to be resumed.
This fixes bug 10732489 except immediately after boot. Pausing the
initial activity if the lockscreen is visible after boot is deferred
for another CL.
Change-Id: I323262596ae41bc5a2700bae5942f6a4fba80936
...in ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Add more debug output to help track down what is going on.
Also fix a little problem where, when a service ANRs, if you ask to
wait and it still wasn't responding, the ANR dialog wouldn't be
shown again.
Change-Id: I5be2b1705a0a39ca2992624ae683945c5f38065d
Gah I messed up when refactoring so it would always be told
RAM is low.
Also slightly tune the low memory parameters to go into low
memory states a bit more aggressively.
Change-Id: I5f970349760ad349d515a85c266ab21b387ee353
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
At some point during refactoring of ActivityStack, the code to pause the current
activity got deleted. Added back that line of code. Activity will now pause
as soon as the screen is turned off, rather than after 5 seconds (sleep timeout).
Bug: 10632898
Change-Id: If3cc8708d692d29a13dbd8cfd9edda8883b38c2e
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
...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services
currently starting (still set to 1 for svelte devices, 3 for normal
devices).
Add new intent flag to not allow receivers to abort broadcasts, which
I use to fix an issue with the initial BOOT_COMPLETED broadcast not
actually requesting pss data at the right time -- it can now be sent
as an ordered broadcast without the ability for the receivers to cancel
it.
Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
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
