Haven't found the underlying cause, but this will give us more
information when we get into the bad state.
Change-Id: I9aebd3a025a7c0d931f43098461b64ee3c220746
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
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
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
ProcessStats is now called ProcessCpuTracker.
ProcessTracker is now ProcessStatsService, and its inner State
class is broken out into a separate top-level ProcessStats class.
This ProcessStats is moved to the framework, so we will be able
to use it elsewhere.
Change-Id: I6a127bcb835b6b474b72647c0b99b82c2137e5c5
