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
Bug #9425270
A better solution would be to use glCopyTexImage2D whenever possible but
this change would be a little more dangerous.
Change-Id: Ib1aaceda39d838716285ef97f356721416822dbb
Removes onWakeKey/Motion handling from keyguard since it's no longer used.
The legacy code was originally intended to have keyguard filter wake events
which is now done in PhoneWindowManager. Ultimately it just needs to call
PowerManager.wakeUp() since keyguard no longer filters these keys.
Change-Id: I5b8ef9b422abf850a85b57f21944e5eb09fbedc2
Bug #9589379
If the atlas is terminated/reinitialized and a view does not invalidate
in between it might end up using a stale AssetAtlas::Entry. This change
is similar to how 9patch meshes are cached in DrawPatchOp: we simply
track the generation ID of the cache to make sure we always use the
latest data.
Change-Id: Ib5abb3769d2ce0eabe9adc04e320ca27c422019e
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
Bug #9425270
When a TextureView is detached from its window and immediately
re-attached, the display list is not destroyed but reused as is.
TextureView will however destroy the layer and surface texture
reference by the display list.
The solution is to force TextureView to invalidate its display
list on re-attach if it previously had a surface/layer pair.
Change-Id: I475096ffa7e5709155c4c943bf1bfaaaedbd4a1d
When registering for a specific setting key uri, the observer
can also be called back for "parent uri" updates. e.g.
adb shell content update --uri content://settings/secure will
trigger onChange with uri=content://settings/secure.
Add a quick setting value recheck, and avoid restarting if
the setting value change will have no impact.
Bug: 9595731
Change-Id: I4c71f6a4be3b655b31d2535e809bb42edd931cd6
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
