cb15c7a83b62a37e5def14413e37925391e5ea39 |
|
07-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
More on issue #12031685 (DO NOT MERGE) Integrate from master: 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: Iffdea96f867f89089e7ad07b4b1bef056951a5e8
/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
|