- New Activity.reportFullyDrawn() method that applicatins can call
when they know they are fully drawn, allowing us to have better
app launch time info. This data is also included in usage stats.
- Added total and free memory data "dumpsys meminfo".
- Tuned the moderate memory levels to be more aggressive about
considering the device getting low on RAM, and thus starting
to prune RAM from processes.
- Fixed issues in processstats when reading old data as well as
resetting and other various fixes.
Change-Id: I20efe7451afb4edfa1aeec448328ba601c24d869
No longer compile libandroidfw as a static library on the device
since it already exists as a shared library. Keeping the static
library would force us to provide a static library version of
libinput for the device as well which doesn't make sense.
Change-Id: I3517881b87b47dcc209d80dbd0ac6b5cf29a766f
This change disables 'Scan Always' by ignoring the setting; and
hard coding value to 'false'. The UI will change based on whatever
is in settings; but underneath we won't enable scans when WiFi is
off.
Change-Id: Ibb1401207b6675e609e979ea23b63177814f762c
We now persistent the current procstats to storage
to keep them across boots. Still need to do division
and pruning across days; right now they will just keep
collecting forever.
Also fix some bugs in the checkin output.
Change-Id: I4dd9317dbe2ee0642af8f2f0be1f2bd9c4055e80
Setting the focus to the top activity on the home stack when
changing stack. This got lost when setting the stack to the foreground
no longer set automatically set focus.
Fixes first half of bug 9580068.
Change-Id: Ic9a662579399c052e0f0992651a32094f4aa62d0
Various applications such as Skype and our legacy VPN code
do not understand routes pointed directly at point-to-point
interfaces and require a default gateway IPv4 address in
order to function.
Grudgingly accept that routes without default gateways Are Hard
and use gatewayed routes instead. This causes routing to go from:
default dev clat4 scope link
to:
default via 192.0.0.4 dev clat4 scope link
192.0.0.4 dev clat4 scope link
and those apps now work.
Bug: 9597256
Bug: 9597516
Change-Id: I7b7890873802d3cb99affd6eb70b8ab75e7a2cf6
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)
