The activity manager now uses some heuristics to try to
sample PSS data from processes so that it can get enough
data to over reasonable time have something useful, without
doing it too aggressively.
The current policy is:
1. Whenever a significant global change happens (memory state,
sceen on or off), we collect PSS from all processes; this will
not happen more than every 10 minutes.
2. When all activities become idle, we will collect PSS from the
current top process; this will not happen more than every 2
minutes per process.
3. We will sample the top-most process's PSS every 5 minutes.
4. When an process's oom adj changes and it has been more than
30 minutes since PSS has been collected from it, we will
collect a new PSS sample.
5. If a process changes from service A to service B (meaning it
has been running a service for a long time), we will collect
a PSS sample from it.
6. If someone explicitly requests PSS data (for running services
UI or dumpsys), record that.
Also:
- Finish moving the procstats output all to the new format.
- Record information about processes being killed due to excessive
wake locks or CPU use in procstats.
- Rework how we structure common vs. per-package process stats to
make it simpler to deal with.
- Optimize the Debug.getPss() implementation (we use it a lot now).
Should probably optimize it further at some point.
Change-Id: I179f1f7ae5852c7e567de4127d8457b50d27e0f0
As a prelude to introducing fancier scoring functions, this CL
moves scoring and everything that depends on it into a handler.
This allows the NotificationManagerService to report back to the
calling process right away about whether or not the notification
is valid; not blocking while score is computed, and non-statusbar
notification modalities are activated.
Change-Id: Iaf77bc89544bb7bcb7adeda60885d74c3170541c
I made the power manager more rigid, not allowing different uids
to use the same wake lock. This never should happen. I would
guess there is somewhere that the activity manager is acquiring
the wake lock without clearing the calling identity... but it is
hard to follow all the paths this may happen in. So here we add
some checks when acquiring/releasing the wake lock to make sure
it is being done as the system uid.
Also:
- Protect the new activity stack calls with a permission, and
make sure to clear the calling uid once past that.
- Collect uid data from process stats so we can correctly
associate CPU use with a uid even if we don't know about the
pid for some reason.
- Fix battery stats dump commands to clear calling uid before
executing so they aren't broken.
Change-Id: I0030d4f7b614e3270d794ecfc3669139a5703ce9
This and the old isHighEndGfx() is set up through a
device configuration, rather than trying to compute it
automatically.
Change-Id: Ibc95c05791023a7ae6c88555b75bb61f2b613991
JBMR2 runtime restart (system process crash in the sync manager) during setup
The fix is to ensure that all access to SyncStatusInfo and related objects happens
while holding the mAuthority lock or is on a per-thread copy of the objects
Also, includes an unrelated fix for a bug I just noticed in the way
dumpSyncState() prints the periodic sync info
Change-Id: Id9e4dff41029412e133bdabc843d555434d9a12f
(cherry picked from commit 182ff3acbad9850b40d37ad1c23106be6eda8476)
Completely reworked how it manages its data, since trying
to keep track of all of the possible pss data with the old
data structures would have made it huge. Now we have a sparse
data structure for pss and process times. (Will switch service
times over to it soon.)
Currently the only thing that collects pss data is running
"dumpsys meminfo". More will be added later.
Modified checkin output to also scale better as more distinct
data categories are added, and added output of pss data. Now
instead of dumping every possible entry as a comma-separated
list, it dumps a comma-separated list of only the entries with
data, tagged with the state they go with.
Also fixed some problems in the checkin reporting of batterystats
(it needs to escape commas), added checkin reporting of the history
list, fixed parsing of kernel wake locks to strip quotes, fixed
wake lock name that the sync manager generates to be more sane.
Change-Id: Ibf4010838a9f685ebe1d93aff86c064ccc52b861
- Sending a broadcast indicating when scan requests could be serviced so that
apps don't request scans we won't do anything with.
- Fix our batt stats accounting so we only count it if we send the request to
the driver.
bug: 8868201
bug: 9496690
Change-Id: I64a4f1c294c848ac64c50d8854ed4a6a1a47f603
Introduces a new "blocked" state for each package. This is used to temporarily
disable an app via Settings->Restrictions.
PIN creation and challenge activities for use by Settings and other apps. PIN
is stored by the User Manager and it manages the interval for retry attempts
across reboots.
Change-Id: I4915329d1f72399bbcaf93a9ca9c0d2e69d098dd
One problem this turned up is, because FastPrintWriter does
its own buffering, a lot of code that used to use PrintWriter
would fail -- if it pointed to a StringWriter, there was no
buffering, so it could just immediately get the result. Now
you need to first flush the FastPrintWriter.
Also added some new constructors to specify the size of buffer
that FastPrintWriter should use.
Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
The determination for whether to launch home after an app dies
did not include whether the app would have returned home on exit.
This fixes that by checking what the app would naturally return to.
Fixes bug 9466261.
Change-Id: Ife6e895b9ef8c11b0a7f470d3eac4e88e763930b
Changing the focus to a new activity should not move it to the top of
the task stack. When the previous activity fully pauses and the new
focused activity resumes then it will be brought to the top of the
task stack at the proper time. Moving it there prematurely causes the
ActivityManager and WindowManager stack sequences to be out of sync.
Fixes bug 9518153.
Also remove false warnings in validateTopActivitiesLocked() and add
debug for task movement to TaskStack.
Change-Id: Ib57500b07ded97223155cda7ef603aecc9b642c3
Earlier CL, ag/321609, was overly aggressive. It should only have kept
the stack from moving when moveTaskToStack() was called. Instead the
change was applied to moveTaskToFront() as well. In order to remain
consistent with earlier behavior of moveTaskToFront() the stack
containing the task must move to the front as well. This movement
launches the activity at the top of the task. Without the stack
movement the activity never gets launched causing bug 9498455.
Fixes bug 9498455.
Change-Id: I2cb9119c23a226f7d211851df9e49f10f702b3ef
First step in adding activity specific information to displays.
Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that
holds an activity token in addition to the CompatibilityInfo.
Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
