| d052a9416ae3f7e42fc1e7de0740021df385ee48 |
|
22-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #18486438: Reduce size of bugreport output
Reduce how much stuff ProcessStats spews, and do collapsing of
repeated intent filter targets when dumping IntentResolvers.
Also add to pm's checkout output to include shared user ids,
and fix output formatting in a few places.
Change-Id: Ic9fc6731f0439101ba9343535e66cdbbad47e291
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| fabb70b2efbd125f74923d19ab12bc8e1371ed1f |
|
11-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Add reporting of Parcel memory/count.
Also fix issue #18340771: Dumpsys Procstats missing a newline
Change-Id: I0c612187a3fb4d7eeafbf97d373efdef732c477e
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| ab4a81b3c625e33d04ae8070fcce6b6baee6522c |
|
10-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Improve some docs, fix some debugging.
- Add docs to Binder, Messenger, ResultReceier to explain their
relation (or lack there-of) to process lifecycle.
- Clarify some aspects of process lifecycle for services.
- Fix help text of am command.
- Fix per-package dumping of battery stats to not include history.
- Fix per-package dumping of proc stats to only include aggregated
and current stats and fix some formatting.
- Fix per-process dumping of meminfo to have an option to interpret
the input as a package, so including all processes that are
running code of that package.
- Fix top-level per-package debug output to correctly include all
of these improvements and give them a little more time (10s) to
complete for timing out.
Change-Id: I2a04c0f862bd47b08329443d722345a13ad9b6e2
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 25e1ecaabbde4741663c8e5a777d9df9b939572c |
|
23-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #17614177 APR: system process restarting due to infinite loop
Also try to get rid of a huge wtf we are seeing across a lot of devices
where we incorrectly change real states on a service that is restarting,
and get rid of one of the noisier boot logs in the package manager.
Change-Id: I2510b6fb082eac3f6168cbd57bc3b70ad006114d
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| f7097a5b697fedb6976774e55a51471405a23c0e |
|
13-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add kernel and native memory data to procstats.
We now collect memory use data in the kernel and native
application for aggregation in procstats. This should
allows us to do aggregated summaries of how memory use
is distributed across the system -- how much is free vs.
how much is in use.
Fix a bug in how we were tracking per-app version codes:
apps that used a shared user id to have multiple packages
run in the same process could get their version codes
cross-wired. Now we keep track of version codes in the
list of packages associated with a process.
Bumped the checkin version code to 5, so that we can
distinguish checkins that have this corrected data.
Also fix a bug in battery stats monitoring radio state.
Change-Id: I1c849f2df442df679a34ad7b0ca0c5870bfac8df
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 3c1ff826e0abdffdd76129bf974abb96444dade8 |
|
28-May-2014 |
Brian Carlstrom <bdc@google.com> |
Move to dalvik.vm.lib.2 to force default to libart
Bug: 14298175
Change-Id: I8afa91bddfb6fec6b61c39286a16594eb947830e
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 2bfd9839aa04265e3c170b1743c08001a2d9313b |
|
09-May-2014 |
Selim Gurun <sgurun@google.com> |
Cleanup remainings of old webview.
Cleanup some code that remained from old webview.
Change-Id: I7b654a40284ff88a0a42c7407ad0b2499000f77d
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 776abc24cdd18610232a50b997cce3cffa74609b |
|
07-Mar-2014 |
Adam Lesinski <adamlesinski@google.com> |
Uses VMRuntime.newUnpaddedArray for ideal array sizes
Bug:13028925
Change-Id: I0a9301248b10a339afbdc5e4ffe3310ac4fa1fb7
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| dfc60ec523674ac5c72fd88a23999e80b2dd72d1 |
|
19-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #13065185: Frequent runtime restarts on launching...
..."Hill Climb Racing" app
A service is in use when it is in the restarting state.
Change-Id: Ic92a6e7bcc24b01aeef5f97f994f105d5e11ea7f
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| fdb98d477047f6dfdbd9e94a7b326d35ad78c6c8 |
|
30-Jan-2014 |
Brian Carlstrom <bdc@google.com> |
frameworks/base: Rename persist.sys.dalvik.vm.lib to allow new default
(cherry picked from commit c6c633608ad4cd77ed21227b0bdb11eb79797c31)
Bug: 12798969
Change-Id: Ibb7ed86867e4dca53ad7fe33326b08e6f5e664c4
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 8472e6189cd4e0520c047bdb28457abc728b373f |
|
24-Jan-2014 |
Dianne Hackborn <hackbod@google.com> |
Add app version codes to procstats.
Now the per-package proc stats data is also per-app-version-code.
In addition to changing the data structure to have one more
SparseArray and passing a version code all over, this also required
improving how we reset the stats so that we can prune a multi-package
process record back to a single package. Otherwise, as you install
updates to apps, the proc stats data would continue to explode as
the data for each of those app's processes got turned to a
multi-package due to tracking the old and new versions at the
same time.
This also bumps the checkin version code, since the package entries
also include a new field for the app version code.
Change-Id: I80de36addb0a75c7b08aef747c6f6c8012d01ee4
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| daa0d5c9296515fe05cae65926a66dee609f382a |
|
07-Nov-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11223338: Not retaining service started state while restarting
When I cleaned up how we maintained the lifecycle of the tracker with a
service, I broke most tracking of the service restart state. (Since at
that point the service is no longer associated with a process, so I
must clean up the tracker state). This change introduces a new special
case for interacting with a service tracker to explicitly tell it when
a service is being restarted. It also fixes how we update the process
state when services are attached to it, so it goes in and out of the
restarting state correctly.
In addition:
- Maybe fix issue #11224000 (APR: Dependent processes not getting added
to LRU list). We were not clearing ServiceRecord.app when bringing
down a service, so if for some reason there were still connections to
it at that point (which could happen for example for non-create bindings),
then we would so it when updating the LRU state of that client process.
- dumpsys procstats's package argument can now be a package or process
name, and we will dump all relevent information we can find about that
name.
- Generally improved the quality of the dumpsys procstats output with its
various options.
- Fixed a bug in ActivityManager.dumpPackageState() where it would hang if
the service was dumping too much, added meminfo to the set of things
dumped, and tweaked command line options to include more data.
- Added some more cleaning code to ActiveServices.killServices() to make
sure we clean out any restarting ServiceRecord entries when a process is
being force stopped.
- Re-arranged ActiveServices.killServices() to do the main killing of the
service first, to avoid some wtf() calls that could happen when removing
connections.
Bug: 11223338
Bug: 11224000
Change-Id: I5db28561c2c78aa43561e52256ff92c02311c56f
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 237cefbcee8721e3268ba778297a0ad48e67f079 |
|
23-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11323037: Android apk incorrectly marked as running in app processes
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
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 878deb3c7b33a0c508137143c776e07bab0296cf |
|
15-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11223335: APR: Lots of failures in procstats due to...
...bad cleanup of crashing processes
We now have a special path for crashing processes, to silently
clean up their state.
Also some tweaks to Log/Slog.wtf to get better stack crawl
summaries in APR.
Change-Id: Ieced26989907a6e7615b6fa033813fced78d7474
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 164371fb759bad6854570af0fca60d9a01e17235 |
|
02-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11005453: [SUW] G+ profile creation for new user broken
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| cb4285537b1bf67b5a248e509d5fe41a6f49282e |
|
26-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10948509: Crash in procstats when there is no data
Not dealing with the case where there is a null list.
Also fixed some bugs I found while looking at this:
- When resetting the stats, we would use a newly computed time stamp
for the total durations rather than the one we used to reset the
proc/service entries. This would result in them being able to be
slightly > 100%.
- There was a bug in how we split a single process state into its
per-package representation, where we would but the cloned process
state into the new package's entry (instead of properly for its
own package entry), to be immediately overwritten by the new
process state we make for that package. This could result in
bad data for processes that have multiple packages.
- There was a bug in resetting service stats, where we wouldn't
update the overall run timestamp, allowing that time to sometimes
be > 100%.
- There was a bug in computing pss data for processes with multiple
packages, where the pss data was not distributed across all of the
activity per-package process states.
- There was a bug in computing the zram information that would cause
it to compute the wrong value, and then never be displayed.
Finally a little code refactoring so that ProcessState and ServiceState
can now share a common implementation for the table of duration values.
Change-Id: I5e0f4e9107829b81f395dad9419c33257b4f8902
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 3bc8f78d7a3d23a67c06221cc41292d04a2fd439 |
|
19-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #10691475: Kill cached processes if about to...
...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
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 53459a7020dbcd036e2d3418e35ebb96fadc29e3 |
|
18-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #10797796: IllegalStateException in ProcessState...
...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
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 50ef0b62f076c509d5edaef5588080d685f063e8 |
|
17-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #10771346: runtime restart
Haven't found the underlying cause, but this will give us more
information when we get into the bad state.
Change-Id: I9aebd3a025a7c0d931f43098461b64ee3c220746
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| a0332377e1edb95202249412ef7bb06a4e1aec03 |
|
14-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #10748810: Runtime restart: crash under...
...ActivityManagerService.setProcessTrackerState
And if not, at least we'll have a little more debug info
when it happens again.
Change-Id: I685f0f72c2e1b17608a8d069d6c7f2cff2fd0abd
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| be4c1d74a758f40de25e796a991ccfd1fe356857 |
|
09-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10671878: Proc stats needs to remove old data structures
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
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| ae36b236d2b8d040f142bee169742da2f392efaa |
|
04-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10427108: Google+ has long running process
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
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 69cb00b8dda60eff7449b69723f4e73a28e944f8 |
|
10-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
More stuff I need for the proc stats UI.
Change-Id: I5f05b79bc4d5766a80f2db9d20ba8078b60c1b00
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 60444fd594ac92aa48e229c600c2ce7de4caf2d1 |
|
09-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Add method for adding two ProcessStats objects together.
Also move file reading code over to ProcessStats.
Change-Id: Ib42272b90a408a494044965e98beed16c0b3f8a5
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|
| 8a0de58ece89c467c8e7415097d193e5f8db9db8 |
|
08-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Get ProcessStats callable from other processes.
Also fix a bug where, when parceling the stats, we were
computing the final duration values too late. We need to
do that before we write the long table.
Change-Id: Idb6c1ed95417448c56973fe5866bfb3570e525f4
/frameworks/base/core/java/com/android/internal/app/ProcessStats.java
|