PAC (Proxy auto-config) files contain a single javascript function,
FindProxyForURL(url, host). It gets called to determine what proxy should be
used for a specific request.
This adds PAC support to the system. The ProxyProperties has been modified
to hold the PAC file when one is present. The Proxy method
setHttpProxySystemProperty has been modified to insert a PacProxySelector
as the default ProxySelector when it is required. This new ProxySelector
makes calls to the ConnectivityService to parse the PAC file.
The ConnectivityService and the WifiConfigStore have been modified to support
saving the extra PAC file data.
The ConnectivityService now has a class attached (PacProxyNative) that
interfaces to the native calls for PAC files. The parsing of the PAC file
is handled by libpac (which is being added to external/) which utilizes
libv8 to parse the javascript.
As a fallback to applications that don't use the java ProxySelector, the proxy
is setup to point to a local proxy server that will handle the pac parsing.
bug:10182711
Change-Id: I5eb8df893c632fd3e1b732385cb7720ad646f401
Add Service.onProvideAssistData(Bundle) which will be
called on foreground Services that have the new attr
in their manifest of provideAssistData = true;
Rename private reference to e.g. "getTopActivityExtras"
as "getAssistContextExtras" - do not rename the relevant
permission, since it is already public.
In ActivityManagerService, request extras both from the
top activity and from any foreground services with the
above attribute. Extend PendingActivityExtras as
PendingAssistExtras with a list of Services from which
extras are expected.
Reduce the timeout to or reporting extras from 4 sec to
just 500 ms.
Bug: 9526331
Change-Id: Ia03b96e8189033a68ae9c514c8cea0199a19bce8
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
The goal is to collect PSS data from processes when they
are in as stable a state as possible. We now have tables
for the durations to use for PSS collection based on
process state, and scheduling of collection is all driven
by process state changes.
Change-Id: I95e076f6971b9c093118e53dc8240fb3f5bad3b2
Fix a problem where we would not respect the device's
override display density/size if those had been reset at
some point (to an empty string).
Tweak the tuning of low RAM devices to consider 480x800 as
the base line resolution. That is our target these days.
Improve output of oom and meminfo to include this tuning
information.
Change-Id: Ic9a85b0391b075178c4ac17e64086ef21889f430
If a service is being executed due to a call from a background
process, there is no reason for its process to be brought up
to the foreground scheduling group to do its work. So, don't.
Change-Id: I0f4f9f2fdcc3481ca4ad2e4e3deb43b8edbbd897
We were now propagating the screen on state when updating
all process states, so they would get pushed into the screen
off bucket always even if the screen was on. Oops!
Also improve the summary output when dumping a single package
to be more summary-like.
Change-Id: I16c640f9dc02d6db8c66aeb1c720f67beab60635
- Make sure Home activity goes in the correct task and on the correct
stack.
- Do not allow different users to be in the same task.
- Do not set stacks aside for each user.
Fixes bug 9775492.
Change-Id: I0e7954e917aac8482a1015a36923e02914e2b692
These new constants are a better mapping to the kind of
information that procstats is wanting to collect about
processes. In doing this, the process states are tweaked
to have a bit more information that we care about for
procstats.
This changes the format of the data printed by procstats,
so the checkin version is bumped to 2. The structure is
the same, however the codes for process states have all
changed. The new codes are, in order of precedence:
p -- persistent system process.
t -- top activity; actually any visible activity.
f -- important foreground process (ime, wallpaper, etc).
b -- important background process
u -- performing backup operation.
w -- heavy-weight process (currently not used).
s -- background process running a service.
r -- process running a receiver.
h -- process hosting home/launcher app when not on top.
l -- process hosting the last app the user was in.
a -- cached process hosting a previous activity.
c -- cached process hosting a client activity.
e -- cached process that is empty.
In addition, we are now collecting uss along with pss
data for each process, so the pss checkin entries now
have three new values at the end of the min/avg/max uss
values of that process.
With this switch to using process state constants more
fundamentally, I realized that they could actually be
used by the core oom adj code to make it a lot cleaner.
So that change has been made, that code has changed quite
radically, and lost a lot of its secondary states and flags
that it used to use in its computation, now relying on
primarily the oom_adj and proc state values for the process.
This also cleaned up a few problems -- for example for
purposes of determing the memory level of the device, if a
long-running service dropped into the cached oom_adj level,
it would start being counted as a cached process and thus
make us think that the memory state is better than it is.
Now we do this based on the proc state, which always stays
as a service regardless of what is happening like this, giving
as a more consistent view of the memory state of the device.
Making proc state a more fundamentally part of the oom adj
computation means that the values can also be more carefully
tuned in semantic meaning so the value assigned to a process
doesn't tend to change unless the semantics of the process
has really significantly changed.
For example, a process will be assigned the service state
regardless of whether that services is executing operations
in the foreground, running normally, or has been dropped to
the lru list for pruning. The top state is used for everything
related to activities visible to the user: when actually on
top, visible but not on top, currently pausing, etc.
There is a new Context.BIND_SHOWING_UI added for when system
services bind to apps, to explicitly indicate that the app
is showing UI for the system. This gives us a better metric
to determine when it is showing UI, and thus when it needs
to do a memory trim when it is no longer in that state. Without
this, services could get in bad states of continually trimming.
Finally, more HashSet containers have been changed to ArraySet,
reducing the temporary iterators created for iterating over
them.
Change-Id: I1724113f42abe7862e8aecb6faae5a7620245e89
The activity manager now keeps a new "process state" for
each process, indicating the general execution and memory
state of the process. This closely follows the out-of-memory
adjustment and scheduling class that it currently tracks,
but roles these together (plus a little more info) into one
more semantically meaningful number.
This value is reported to each process as it changes, so they
can do things like tune the Dalvik garbage collector to match
the current process state.
I think I should also switch to this for process states. It
will give is more meaningful divisions of time for each process.
Also fix a problem in the activity stack where the previous
process was not being set correctly when moving between
activity stacks.
Change-Id: I598b1667dc46547f8fadae304e210c352cc9d41f
Rename convertToOpaque to convertFromTranslucent. Add the
counterpart to Activity.convertFromTranslucent() for returning from
opaque to a translucent Activity. The caller should wait until
TranslucentConversionListener.onTranslucentConversionComplete() is
called before actually changing the background to translucent.
Change-Id: Id04b026bcc4dd8bad9a33a7af126e1bb28fb9c03
The historical data is now a more central part of the stats.
When a checkin happens, the data is not deleted, just marked
as checked in so we can continue to access it.
The default procstats dump is now a new "summary" mode that
shows a more useful set of data for all of the running processes.
By default the current and all committed states are shown; you
use "--current" to only show the current. Use "--details" to
get the previous more detailed data (which now includes detailed
process data like the per-package data).
Also tweaked uid printing to be a little more compact.
Change-Id: I5414ea7c07134ebd5dc83f6f7b9f6e30151eda85
There did not need to be one launching wakelock for each stack.
Moving it to the stack supervisor makes the logic much simpler
and fixes bug 9693439.
Change-Id: I5c9ae856540170a4d66fedb74becb6959c44dd8f
We now keep a small set of historic procstats data. Each
time you reboot a new set of data is created; each day a
new set of data is created. At most 5 sets of historic data
are kept at a time. Each checkin only prints any existing
historic data (and deletes it); checkins do not include the
current data, to keep the checkin data less noisy.
This requires a bunch of re-arranging of the way state is
maintained to allow the multiple files, and loading and
processing state from old files. Also fixed some problems
with writing/reading state.
The checkin format has been tweaked. There is a new "period"
line that tells you (1) the date/time stamp of the data,
(2) the device realtime data collection started, (3) the
device realtime data collection finished. The difference
between the last two give you the real time duration for
which the data was collected.
Also, the third field of pkgproc and pkgsvc-* can now be
abbreviated: if it is the same as the package name, it is
empty; if it is a suffix fo the package name it starts with
'.'.
Change-Id: I422875fccb627d95df7e36c183ac90056f273d83
- 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
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
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
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
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
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
We now keep track of the time actually process run independently
of the time packages run in process, so we can give an accurate
summary of how long each physical process runs.
New command line options can be supplied to restrict printing to
a specific package, dump in a new csv format, control what is
printed in the csv format, and print a checkin report.
Add toString methods to ArrayMap and ArraySet.
Change-Id: I47b8f68472592ecc0088c5286d3564aa615f4e0a
Set the focused stack to the task with the started activity. Do not refocus
when activities report resume.
Add more conditional debug.
Fixes bug 9481679.
Change-Id: Ib7134e88f9a2c8ad1703af0d43442c8bbe4e65dc
Re-arranged code to be more flexible, now track
state of services, dump ordered list of running
processes while memory was critical and low.
Also rename battery stats service from "batteryinfo" to "batterystats".
Change-Id: I0f4f0c8d443c49d255cb84d0fc917e8ec18b152e
We now keep track of when each process is running, batched
by the current memory status of the device. In addition,
the stats are organized by package first, and then processes
associated with each package inside of that. Finally, we
also keep track of the overall time spent in each memory
status.
This should start to actually get us to some information
we can reach some conclusions about. The total time spent
in each memory status gives us some indication of how much
we are running while memory is low; the new package organization
batched by memory status lets us see what packages have
what processes running when memory is low.
Change-Id: I389d62d39d115a846126cf354e4c20070d8f1180
Adds a platform API, and pm command. Fixes some issues with
dumping per-package data in package manager, makes battery
stats able to dump per-package state.
Change-Id: I76ee6d059f0ba17f7a7061886792b1b716d46d2d
The goal of this is to keep track of what app processes
are doing, to determine who is being abusive, when the system
is getting into memory constrained situations, and help the
user determine how to resolve this.
Right now it doesn't really do any of that, just keeps track
of how long every process has been running since boot.
Also update the activity manager to use "cached" as the terminology
for what it used to interchangeably call hidden and background
processes, and switch ProcessMap over to using ArrayMap.
Change-Id: I270b0006aab1f38e17b7d9b65728679173c343f2
