...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
Fixes bug that double tapping on an entry in the intent disambig dialog
can result in the picked activity being launched twice.
Bug: 10770501
Change-Id: Ibb7c6bea5f3c25fa204a2f0e65c8044c2a2549f7
...caused runtime restart
There were some situations where the package list could be set
with process stats when it shouldn't. Not sure if this is causing
the problem, since there is no repro.
Also some improvements to debug output -- new commands to clear
all stats, print full details of stats, and print a one-day
summary (which should match what the UI shows).
Change-Id: I9581db4059d7bb094f79f2fe06c1ccff3e1a4e74
Make sure we beginDelayedTransition when we expand and collapse action
views, specifically before any callbacks go out that might alter the
hierarchy.
Change-Id: Iffc286cccd9be83ad03aeede605870ac12cc6bab
Haven't found the underlying cause, but this will give us more
information when we get into the bad state.
Change-Id: I9aebd3a025a7c0d931f43098461b64ee3c220746
Keystore stored keys broke when keyguard was moved out of the system process
due to Keystore enforcing the calling app to be in the system process.
The fix moves the critical code into LockSettingsService, which continues
to live in the system process.
Fixes bug 10201270
Change-Id: I16e2de018e85b01265634dcfbefd7f06740dafa8
...ActivityManagerService.setProcessTrackerState
And if not, at least we'll have a little more debug info
when it happens again.
Change-Id: I685f0f72c2e1b17608a8d069d6c7f2cff2fd0abd
This significantly reworks the logging we do when
all cached processes are killed:
- We now collect the list of processes in-place so we
have a snapshot of exactly when the low memory situation
happened.
- In that snapshot we include the key process state: oom
adj, proc state, adj reasons.
- The report then asynchronously collects pss information
for those processes.
- The ultimate data printed to the log looks like a mix
between the "dumpsys meminfo" and "dumpsys activity"
output. This code no longer uses "dumpsys meminfo"
itself, so some of that data is no longer included,
in particular pss organized by allocation type.
In doing this, I realized that the existing code that is
supposed to run "procstats" is not currently working. And
at that point I realized, really, when we are collecting
this pss data we'd really like to include all those native
processes using ghod-only-knows how much RAM. And guess
what, we have a list of processes available in
ProcessCpuTracker.
So we now also collect and print information for native
processes, and we also do this for "dumpsys meminfo" which
really seems like a good thing when we are printing summaries
of all pss and such.
I also improved the code for reading /proc/meminfo to be
able to load all the interesting fields from there, and
am now printing that as well.
Change-Id: I9e7d13e9c07a8249c7a7e12e5433973b2c0fdc11
Provide a softer transition to the overflow-everywhere world for
devices with menu keys. The panel menu will still be used on these
devices in response to a menu key press even in the presence of an
action bar with overflow.
Fix a few lingering bugs around dispatching the open-overflow
transition that caused problems with this along the way.
Change-Id: I9d77c70f6d15c47160ac06292984101d619c44e6
* Remove the extra occurrence of the Up caret view and reuse the
standard home view.
* Use new transition APIs to animate changes in action bar content.
Change-Id: I7af3bb580ef4bff7d8dec9e21649b856fe73c77b
We now keep track of which process and service states are actively
in use, and remove any that are not in use during a commit. The
activity manager needed to be tweaked to report this data, and ensure
it does not try to operate on one of these structures when not in
use.
Also some other fixes:
- We now keep track of process names associated with services, for
display in the UI.
- Keep track of total run time for each service, also for UI.
- The parceled format is more efficient, not storing duplicates of
process/package names, and writing times as ints when possible.
- Reduced commit period from 1 day to 12 hours, so that our UI can
be a little closer at its attempt to display the stats over 1 day.
Change-Id: Ifeda0ffe963a7b49d8eb2a3f6923f3a5e71a4e43
Currently missing support for region anchor points, robust layout
when snapping to lines, and vertical text.
BUG: 10260603
Change-Id: I3463b4aa0039442159144e66922d67f5dfee58ed
The calling package is important for ContentProviders that want to
grant Uri permissions as a side effect of operations, so offer it
through a new API. Validates the provided package against the
calling UID before returning.
Bug: 10626527
Change-Id: I7277880eebbd48444c024bcf5f69199133cd59e4
There was a bug in counting the number of starting services
in a process that would cause it to count too many (it would
increment at any state change while the service is started, not
just when starting/stopping).
Also reduce dumpsys output -- only print summaries for old
data. There is probably no utility in printing the long details
of all that data.
Change-Id: I1c1e901b0214c01eb7d071f23166fc6f3702ca67
As per Rachel. Remove the title, change the hint text.
Don't make the dialog disappear after failed attempts.
Bug: 10542734
Change-Id: I1cae3d74bd4da06364626d63faf945f629cf6537
Keep track of last chosen activity for a particular intent, similar
to how it is tracked for "Always" choices.
Pre-select the last chosen activity if previously the user picked
"Just once".
Downgrade "Always" to "Last chosen" if there's a new kid on the block,
instead of removing it entirely.
Add methods to set and get last chosen entry.
UI - switch from Grid to List.
Bug: 9958096
Change-Id: Ied57147739a3ade1d36c3a7ec1e8ce77e5c5bb16
