| 9357b11a798b804b69907f93437229cac1d82468 |
|
04-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10901205: Shouldn't send broadcasts (or try to bind services, etc.)...
...to crashing processes.
So don't.
Change-Id: I4b4fefb501b430fadaca93405206264318c8b95d
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| cbd9a52f256087426feb19ac6e51eff772e81375 |
|
25-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10903002: com.facebook.katana keeps itself in A Services
Now when memory low, if a service's process is above
a selected pss, then the process is not allowed to go
in to the service a list.
Also simplified the normal meminfo details dump to not
include the shared dirty and shared clean sizes by
default, since these can be very confusing. You will
still get to see them with the "-a" flag.
Finally some small steps to better managing service
processes in the LRU list, so hopefully we can some
day be better about letting them drop down in the list
when there isn't really much interesting happening in
the process. Not yet used at this point.
Change-Id: I654bfd6d05de2a63120185ebb15ffda8cbeb5dac
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 3bc8f78d7a3d23a67c06221cc41292d04a2fd439 |
|
19-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #10691475: Kill cached processes if about to...
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 53459a7020dbcd036e2d3418e35ebb96fadc29e3 |
|
18-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #10797796: IllegalStateException in ProcessState...
...caused runtime restart
There were some situations where the package list could be set
with process stats when it shouldn't. Not sure if this is causing
the problem, since there is no repro.
Also some improvements to debug output -- new commands to clear
all stats, print full details of stats, and print a one-day
summary (which should match what the UI shows).
Change-Id: I9581db4059d7bb094f79f2fe06c1ccff3e1a4e74
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| e56c2c3f059b24c968a3f28f701b6b6cf5883fd9 |
|
17-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10795385: System process crash reinstalling GEL -
NPE at com.android.server.am.ProcessRecord.resetPackageList(ProcessRecord.java:596)
Take care of some more cases now that baseProcessTracker can be null.
Change-Id: I394c0b7802788118c3ad6bcac5dfdd23eeda8d58
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 35f72be50b8a2d11bce591dcdac5dc3fa336dac0 |
|
16-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #10691359: Kill long-running processes
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 8e69257a9c7e9c1781e1f53d8856358ada38921d |
|
11-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement #10749688: Improve low memory reporting
This significantly reworks the logging we do when
all cached processes are killed:
- We now collect the list of processes in-place so we
have a snapshot of exactly when the low memory situation
happened.
- In that snapshot we include the key process state: oom
adj, proc state, adj reasons.
- The report then asynchronously collects pss information
for those processes.
- The ultimate data printed to the log looks like a mix
between the "dumpsys meminfo" and "dumpsys activity"
output. This code no longer uses "dumpsys meminfo"
itself, so some of that data is no longer included,
in particular pss organized by allocation type.
In doing this, I realized that the existing code that is
supposed to run "procstats" is not currently working. And
at that point I realized, really, when we are collecting
this pss data we'd really like to include all those native
processes using ghod-only-knows how much RAM. And guess
what, we have a list of processes available in
ProcessCpuTracker.
So we now also collect and print information for native
processes, and we also do this for "dumpsys meminfo" which
really seems like a good thing when we are printing summaries
of all pss and such.
I also improved the code for reading /proc/meminfo to be
able to load all the interesting fields from there, and
am now printing that as well.
Change-Id: I9e7d13e9c07a8249c7a7e12e5433973b2c0fdc11
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 9210bc85545f31973c957b5179e6a82d05f473c6 |
|
05-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement #10744011: Serialize running of background services
Added some code to the activity manager to keep track of
services that are launching and limit the number that can
be launched concurrently. This only comes into play under
specific circumstances: when the service launch is a background
request (so timing is not important) and its process is not
already running at a high priority.
In this case, we have a list of services that are currently
launching and when that gets too big we start delaying the
launch of future services until currently launching ones are
finished.
There are some important tuning parameters for this: how many
background services we allow to launch concurrently (currently
1 on low-ram devices, 3 on other devices), and how long we
wait for a background service to run before consider it to be
a more long-running service and go on to the next pending
launch (currently set to 15 seconds).
Also while in here, did some cleanup of the service code:
- A little refactoring to make per-user data cleaner.
- Switch to ArrayMap.
Change-Id: I09f372eb5e0f81a8de7c64f8320af41e84b90aa3
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| be4c1d74a758f40de25e796a991ccfd1fe356857 |
|
09-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10671878: Proc stats needs to remove old data structures
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| d2932243e3313b59e7538641731aa98852bc5ac7 |
|
06-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Refactor ProcessStats, ProcessTracker.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 8eea0fcd3b4a9c58ba70ea80ed0332d37ac43da5 |
|
02-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Add a new process state for "service restarting".
This is a process that is not actually running, but would be
if we had enough RAM.
Also rework how service stats are stored to used the nice
compact structure we are already using for processes.
And fix a bug where when we committed the current state data,
we would mistakenly write it under the name of the *next* state
that is now starting. Ouch.
Change-Id: I9f2b84b8b3f305301fd48dcd9d4e6c232abe8ef9
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f1cca18ae460b66242988a8a6204c4a42b6fa1c1 |
|
01-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Try to improve PSS collection.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| bf36ee2b0c49241e073da14ee1e1a08b8550f3b9 |
|
27-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Allow services to execute in the background scheduling group.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 8585d688f85fa6350fa3509bf4709c60caa33f92 |
|
19-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #9913990: Background processes are being added to...
...the *end* of the process LRU listB
Change-Id: I75c9477b81e10c4e517fd836304467fb3f7ed85e
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| c8230519728b14065effd3b7d4eca273ff86160c |
|
14-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Switch proc stats to use new process state constants.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| a413dc06b2193442a2d956571b829aeb5fb97862 |
|
12-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new proc state constants and delivery.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 20cdcee47d10986969e7e2a53a40a6ecabae3827 |
|
11-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Add -c option to meminfo to dump a compact form.
Also fix a bug in FastPrintWriter where println(long) was
not printing the newline.
Change-Id: Idcb4eaab0c1ec4b992032b5e36478ef11a6533d9
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| a4cc205ee840a5374a96c9635dc5121d82a3eaf9 |
|
09-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
More procstats work.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 2286cdc0cab77e61b75e6fe9a45b91f6e57cd46d |
|
02-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Misc memory stuff.
- 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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| cfc837f7fa43362b5049f648fe1bfdf5a010cc1c |
|
28-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Start really collecting PSS data for process stats.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| a17c0f5e164729210210ad3f75aea72ed34ca330 |
|
21-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
More procstats work: separate global proc account, more dumping.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 78a369c90f61981c9d0ddd5fcbc77202bfbe74f6 |
|
12-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Improve process tracking.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| be4e6aaa0252dd7da28b7aa85beba982538efa46 |
|
07-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Initial super-primitive process tracker.
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
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 390517be2d60dd6e6264150c190c372d89bb331a |
|
31-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Clean up some temporary allocations.
Yay to ArrayMap, letting me get rid of a bunch of temporary
iterators in core code paths like updateOomAdj. (Now I definitely
need an ArraySet to finish that up.)
Also clean up various other things that are doing unnecessary
allocations, clean up some debug output, make more of the debug
output respect package filtering.
Change-Id: Ib4979faf4de8c7912739bc0937c3fa9e7bfcde67
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 58d380d2af8079075e4773a3e5ca6c2820760e3d |
|
19-Mar-2013 |
Christopher Tate <ctate@google.com> |
debuggerd now notifies the Activity Manager about native crashes
The Activity Manager sets up a permission-guarded domain socket, which
debuggerd connects to when a crash happens. If this is successful,
the daemon then mirrors the logged crash report to that socket, then
closes it.
The Activity Manager parses the native crash dump supplied by debuggerd
and forwards it to the standard app-crashed code. The UX result is
that users now see the normal "app has stopped unexpectedly" dialog
with "report" and "okay" options for native crashes, not just for
DVM-mediated crashes.
Bug 8322568
Change-Id: Ie1b279896c603bd74d82d6cfcfd66a8f231da134
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs.
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 5fe7e2a3043d6a8ca933c77ccf95c791b57b221a |
|
04-Oct-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6968859: home not exiting an ANR'd dream
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| b12e1354f25f04e9c9a71da76c6fca858b7d39d0 |
|
26-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #7211766: bindService() to User u0 While u10 is...
...Forground Sometimes Doesn't Take
The main change here is a one-liner in ActiveServices to check the
uid when deciding whether to remove an item from mPendingServices.
This could cause the problem being seen -- if the same service for
two users is starting at the same time, the second one would blow
away the pending start of the first one. Unfortunately I have had
trouble reproducing the bug, so I don't know if this is actually
fixing it. It's a bug, anyway.
The reason so much has changed here is because I spread around
logging and printing of the user ID associated with operations and
objects to make it easier to debug these kind of multi-user things.
Also includes some tweaks to the oom manager to allow more background
processes (I have seen many times in logs where we thrash through
processes because the LRU list is too short), plus to compensate an
additional time-based metric for when to get rid of background processes,
plus some new logic to try to help things like Chrome keep around
their service processes.
Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f02b60aa4f367516f40cf3d60fffae0c6fe3e1b8 |
|
16-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Rename UserId to UserHandle.
This is the start of turning this into a formal public API.
Change-Id: I5786d2c320f1de41a06ed5d0f65adb68967287a0
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| ee7621c0f5de6eca2cfb9fb2b6117fb61e13cc41 |
|
14-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Modify how the background process LRU list is handled.
A long time ago, we had a concept of an "empty" process -- this was
a process that didn't have any interesting components in it, which
would be placed below everything else in the LRU list.
Empty processes didn't work out well, because you could get into
bad situations where you have filled your LRU list with things that
have hidden activities, pushing empty processes to the bottom and
being immediately killed as soon as they go into the list. So this
was removed.
This change brings the concept back, but in a slightly different
form, to address a more specific problem: for people who are switching
between N different applications, we would like to try to keep those
activities available in RAM in a consistent manner. Currently the
previous activities would be killed often quickly and suprisingly,
even on devices with lots of RAM. This is for two reasons:
(1) As you sit in one application, other things going on in the
background will go to the top of the LRU list, pushing down the
previous apps you have visited, even though you aren't aware at all
of these other things executing.
(2) There is a hard limit on the number of background processes
(currently 16) after which they are killed regardless of the amount
of available RAM. This is desireable because if there is lots of
RAM we can end up with tons and tons of processes sitting around,
not really serving any purpose, but using up resources.
To improve the situation, we have again a concept of "empty" processes
but now it means one with no activities. Processes that aren't empty
but in the background list are called hidden. We maintain these as
two parallel lists, each getting half of the process limit: so with
a 16 process limit, you can have at most 8 empty and 8 hidden processes.
This allows us to consistently keep up to 8 recent applications around
for fast app switching; we will also keep around 8 other processes to
make it more efficient for background work to execute again if it needs
to.
Change-Id: Iee06e45efc20787da6a1e50020e5421c28204bd7
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| a93c2c117d502ee57dd27705a0b5efca4bf65011 |
|
01-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Extend process observer to be usable for media routing.
It now has a new callback to report changes in the "importance"
of processes. Rewrote the dispatching code to be a bit more
efficient now that we are sending more reports.
Change-Id: Ie865cfd286455819f04e8c14e9b6fd54d028f8f2
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 6ae8d1821822296df0606c9cd1c46708cc21cb58 |
|
23-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix (mostly) issue #5109947: Race condition between retrieving a...
...content provider and updating its oom adj
This introduces the concept of an "unstable" reference on a content
provider. When holding such a reference (and no normal stable ref),
the content provider dying will not cause the client process to be
killed.
This is used in ContentResolver.query(), .openAssetFileDescriptor(),
and .openTypedAssetFileDescriptor() to first access the provider
with an unstable reference, and if at the point of calling into the
provider we find it is dead then acquiring a new stable reference
and doing the operation again. Thus if the provider process dies
at any point until we get the result back, our own process will not
be killed and we can safely retry the operation.
Arguably there is still the potential for a race -- if somehow the
provider is killed way late by the OOM killer after the query or
open has returned -- but this should now be *extremely* unlikely.
We also continue to have the issue with the other calls, but these
are much less critical, and the same model can't be used there (we
wouldn't want to execute two insert operations for example).
The implementation of this required some significant changes to the
underlying plumbing of content providers, now keeping track of the
two different reference counts, and managing them appropriately. To
facilitate this, the activity manager now has a formal connection
object for a client reference on a content provider, which hands to
the application when opening the provider.
These changes have allowed a lot of the code to be cleaned up and
subtle issues closed. For example, when a process is crashing, we
now have a much better idea of the state of content provider clients
(olding a stable ref, unstable ref, or waiting for it to launch), so
that we can correctly handle each of these.
The client side code is also a fair amount cleaner, though in the
future there is more than should be done. In particular, the two
ProviderClientRecord and ProviderRefCount classes should be combined
into one, part of which is exposed to the ContentResolver internal
API as a reference on a content provider with methods for updating
reference counts and such. Some day we'll do that.
Change-Id: I87b10d1b67573ab899e09ca428f1b556fd669c8c
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 162bc0ea0d7862b92f18d0ce47310a85304205f7 |
|
09-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Some small tweaks to improve memory management.
We now allow processes that currently have stopping activities to
be managed as if they were done stopping, so that memory trimming
can be done before the process goes to the background. Hopefully
this will reduce cases where the processes goes to the background
and immediately gets killed, but wouldn't have had to be killed if
it had a chance to trim its memory.
Also change window memory trimming to always do the aggressive
trimming when memory is critical, even if not on a low-end device.
And tweak web view trimming to not trim for foreground UI events.
Change-Id: I241b3152b52d09757bd14a202477cf69c9b78786
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| a0c283eac33dd2da72235751bbfa4f2d9898d5ea |
|
09-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature for running services in "isolated" sandbox processes.
This reserves a range of uids (for each user) in which these processes
run. These uids are not associated with an application, so they
effectively run with no permissions. When a Service requests to
run in such a process through android:isolatedProcess="true", each
time it is brought up a new isolated process is started with its
own unique uid.
What we have so far gives us the basic infrastructure; more work
remains to further lock down what these uids have access to.
Change-Id: Ibfd27c75619cba61f528f46ede9113f98dc5f45b
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| e02c88af7935c72fb90a478375e61e4a94465587 |
|
28-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on process management.
Introduce a new concept of "B" services. All running services are
classified as either A or B. B services are later in the LRU list.
Their oom_adj is after the home app. This allows us to better pick
services to kill based on how long they have running, and should
reduce the amount that we end up killing the home app.
This temporarly turns on a debug log when the oom_adj of a process
is changed. Sorry, I know it is noisy. This is needed to try to
track down why some processes are being killed.
Also add a flag to the SyncManager's service binding to allow the
syncing process to be more aggressively killed if it has done UI.
This is to address cases we have seen where sync is causing an 80MB
gmail process to be kept around, preventing other process from running.
Now what will happen is that the syncing process will aggressively be
killed by the system, and can then be restarted in a much lighter-weight
state.
Do a little tweak in the power manager to allow us to still do smooth
brightness changes even when the fancy TV off animation is in use.
And get rid of a debug log in the window manager that was accidentally
left in.
Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 905577f6345c014fc2489a8068ea967ba8c18012 |
|
08-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5263361: Browser instance not created in application picker
The resolver activity was hiding the following activity from recents.
Also some other fixes: a little better memory use debugging, removed
some unneeded code from window manager, moved some system activities
into their own process, added some more running process information for
manage apps.
Change-Id: I66687d16989ff965d524b92dc360f37c19199717
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 7d608423b721e0153f37bfd5eba78fcd2489562d |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Move OOM kernel settings to activity manager.
The activity manager now take care of plugging the correct settings
into the OOM killer in the kernel. This is a lot cleaner because
it is really central to how the activity manager works, and nobody
else cares about them.
Taking advantage of this, the activity manager computes what it
thinks are appropriate OOM levels based on the RAM and display
size of the device.
Also a small optization to the package manager to keep a binding
to the package install helper for a bit after done using it, to
avoid thrashing on it.
And some new APIs that are now needed by Settings.
Change-Id: I2b2d379194445d8305bde331c19bde91c8f24751
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| c68c913d357e2955d4bd7ca52829071e531c7825 |
|
29-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Various work on out of memory managment.
- Improve how we handle processes that have shown UI, to take care
of more cases where we want to push them into the background LRU
list.
- New trim memory level for when an application that has done UI
is no longer visible to the user.
- Add APIs to get new trim memory callback.
- Add a host of new bind flags to tweak how the system will adjust
the OOM level of the target process.
Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f0754f5ba7a45b517cffcb3c2c96f2a32aeac06d |
|
22-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix bug where memory trim was not being delivered with correct level.
Also improve how we handle services, keeping track of whether they showed
UI and if so putting them immediately on the LRU list.
Change-Id: I816834668722fc67071863acdb4a7f427a982a08
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 1b64e0d8657463c0f7ce9b068a16a522cdfe7d28 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on death recipient leaks in Activity Manager and Content Service.
This should fix a leak of process death recipients in the activity manager.
Also add debugging of content observers to try to track down what looks
like a leak of them in the content service.
Change-Id: Id6823679493ef0cde5307bb66490ebe31b878556
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| ce86ba86df61de8b34b226a4eb6c23ec33e866e0 |
|
14-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve handling of low memory.
Now classify background processes into a set of bins of how much
memory they should try to clear. The last bin also involves
destroying all activities in that process.
Removed the old code for the simulator that is no longer needed
(yay). The debugging features it had are now integrated into the
regular oom adj code.
Small fixes to load average service.
Change-Id: Ic8df401714b188c73b50dbc8f8e6345b58f1f3a0
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 3f9dd287b99340efaaa257759e71a8f81b2ed113 |
|
09-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Increase activity timeouts when using a wrapper process.
This patch enables the Zygote to tell the ActivityManager when
it has started a process with a wrapper attached so that the
ActivityManager can allow it extra time to start up or process
events.
This is useful when wrapping an app with Valgrind or other tools
which add significant runtime overhead.
Bug: 4584468
Change-Id: I5db6f2f15cd30b0ec40f547d2fadfa216de2926d
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 7dad2c24fa7811c115f850fd2a8f2ecc8874061e |
|
03-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
am 9b94aa18: am e5d37701: am 8ea5e1d7: Fix compat mode bugs when updating apps.
* commit '9b94aa18f78e6c6281202e72b5a7451bc479fe82':
Fix compat mode bugs when updating apps.
|
| 8ea5e1d79eb1f05ee7628b0d45ea8fc8eea5330d |
|
28-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix compat mode bugs when updating apps.
No longer accidentally puts an app into compatibility mode.
Also various cleanup, freezing screen while switching between modes.
Change-Id: Ic1b3958be7800189a93f68e9dee3c5adfc45fe57
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| d5cdd597b895a48ffa9a8e39f8a2504cd9b905c4 |
|
04-May-2011 |
Jeff Sharkey <jsharkey@android.com> |
First pass at NetworkPolicy and activity tracking.
New system service that maintains low-level network policy rules and
collects statistics to drive those rules. Will eventually connect to
netfilter kernel module through NetworkManagementService and "netd".
Begin tracking foreground activities in ActivityManagerService, which
is updated as part of OOM adjustment. Eventually a network policy of
POLICY_REJECT_BACKGROUND will reject network traffic from background
processes.
Change-Id: I5ffbbaee1b9628e9c3eff6b9cb2145fc5316e64d
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| aa9d84c37e05f696ec158dac98ce38cf41e18314 |
|
10-May-2011 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 05be6d6f to master
Change-Id: Ic6a6c5bb300f6f1d43f9ed550b284282b4f16212
|
| e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows.
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 0c5001d776d56bae02a5cc2663286a125d99bc5e |
|
13-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Add APIs to remove tasks.
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 3c4c2b7e6f0674068d13b42d4dcf0fd009df0c49 |
|
06-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3001368: API REVIEW: android.app.Activity
Bye bye, lots of junk.
Change-Id: Idd72fc525851277362b2a1ff3bb0f7865fe655fd
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 287952c35e148811c106bc0f5036eabf20f71562 |
|
23-Sep-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #3022508: Crash during media scan
Don't kill processes for excessive wake lock use, even if they
are in the background, as long as they have running services.
Also fix some problems with this, such as not noting the kill
in battery stats.
And add killing of processes for cpu usage as well, along with
some optimizations to computing CPU usage.
And fix BatteryWaster to be better behaving for testing these
cases.
Add new "monitor" command to am to watch as the activity manager
does stuff (so we can catch things at the point of ANR).
Finally some miscellaneous debug output for the stuff here, as
well as in progress debugging of an ANR.
Change-Id: Ib32f55ca50fb7486b4be4eb5e695f8f60c882cd1
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 0d903a84d04d241a648ec429e3a0e82c712677fd |
|
08-Sep-2010 |
Dianne Hackborn <hackbod@google.com> |
People holding partial wake locks now get blamed for CPU usage.
For the duration of the wake lock, 50% of all CPU usage is now
accounted against the app(s) holding partial wake locks, evenly
distributed between them. This is only while the device is on
battery and screen off.
Change-Id: I3e5c978b792b6ef17bf8540705bfe8343dadd464
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 1ebccf531d1049853b3b0630035434619682c016 |
|
15-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix problems with determining when to kill apps for wake usage.
Also improve debug printing of various times.
Change-Id: Ifcc288fd1bcbf44c069875ba97925b9e7ffe9a48
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 9adb9c3b10991ef315c270993f4155709c8a232d |
|
13-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Various battery info things:
- Now track wake locks in battery history.
- Now track sensors in battery history.
- Some filtering of sensory data.
- Fixes to some data that wasn't cleared when resetting battery stats.
- Print amount discharged since last charge.
And the big part -- keep track of wake locks held per process,
and kill processes that hold wake locks too much while they are in
the background. This includes information in the battery stats
about the process being killed, which will be available to the
developer if the app is reported.
Change-Id: I97202e94d00aafe0526ba2db74a03212e7539c54
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| c27181c7f3e11170ec82807cfa416f0a906ff574 |
|
30-Jun-2010 |
Christopher Tate <ctate@google.com> |
Remove memory monitoring from the system watchdog
This was originally written as an in-case-we-need-it facility, but was
never actually used in production. It also soaked up a surprising amount
of cpu on occasion, as well as doing sketchy things like demoting the
system_server's primary looper thread to the background cgroup at times.
Change-Id: I9a81a8d1e9caea9e0a1277d97785fe96add438d7
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 01e4cfc47d0a2c7e7ab383d2fb23224ec52c0301 |
|
25-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
Some ActivityThread/ActivityManager cleanup.
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 860755faa6bdd3c2aeae49c05b87b5bc080ae60c |
|
04-Jun-2010 |
Dianne Hackborn <hackbod@google.com> |
Add support for heavy-weight applications.
Only one can be running at a time, their process can not be killed,
and a notification is posted while it is running.
Change-Id: I843015723947e0c934ae63a1aeee139327c0bc01
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 906497c574d45d8dfd295b16dece0d0bc32c0895 |
|
11-May-2010 |
Dianne Hackborn <hackbod@google.com> |
Hopefully fix issue #2662536: Why is launcher being killed?
It looks like there was a subtle bug where Process.setOomAdj() could
return false just because the given process doesn't exist, even though
it is documented to only return false if OOM killing is not supported
at all. This would cause the activity manager to fall into its code
path of trying to clean up processes itself, which it does a much
poorer problem at. I am thinking we may be seeing this problem more
now that the activity manager is killing background processes itself
when there are too many of them.
In addition, this change cleans up and reduces some of the logging
around killing processes.
Finally, try to improve process LRU management a bit by taking
into account process dependencies. Any dependent processes are
pulled up in the LRU list with the processes that is actually
moving. Also, we bring a process up if someone accesses its content
provider.
Change-Id: I34ea161f839679345578ffe681e8d9c5d26ab948
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 149427cd903f2100e3cc39bda41b831cd68bc553 |
|
23-Apr-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2621809: Kill! Kill! Kill!
Stop! Stop! Stop! Spamming the log.
Change-Id: I13f432b49d8c85165873566d58e2fb2714b1263e
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| dd71fc8baeee0d09008d0fa67d6bf3d23cf21baa |
|
17-Dec-2009 |
Dianne Hackborn <hackbod@google.com> |
Rework the LRU list for hidden and empty processes.
This is intended to solve a problem on devices with more memory
where we can fill up that memory with processes that contain activities
(hidden processes), leaving no room for empty processes. Thus if a
process is receiving broadcasts regularly, or starting and stopping
a service, or such, we will continually create its process only to
have it immediately killed when done.
There is certainly some tuning that should be done on this as we
look at the actually behavior. The implementation here puts all of
the hidden and empty processes into one list, trying to make some
preferences for the very most recently used activity's processes to
stay at the top and not get pushed out by other processes being
started in the background.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 0c3154d3fc54a1b3d8358a2932042cca729327b9 |
|
07-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2163654: deadlock, runtime restart
Don't hold a lock when the activity thread is telling the activity manager
to release a provider.
This requires that the activity manager now keep a reference count on the
providers, because without the lock it is possible for activity thread to
call in to request the provider again before it has finished telling
about the release.
Change-Id: I5f912903891f4edae85e28819d4e6f14b8f2e688
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| dd9b82c283815747b75fe4434c65e4b6c9c9b54f |
|
03-Sep-2009 |
Dianne Hackborn <hackbod@google.com> |
Add better service reporting.
This will be used elsewhere.
Change-Id: Id561fa7fed5eb65446312cb697813483903d33a6
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| fd12af4e768fec852c4c5dfee3b9bd7403b4b347 |
|
27-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Various tweaks to try to improve low memory behavior.
- Reduce the amount that we ask processes to GC after a significant
operation occurs, but introducing a minimum time between GCs and
using this in various ways to schedule them.
- Don't spam all of the processes with onLowMemory(). Now deliver
these using the same gc facility, so we do the processes one at a
time, and don't allow the same process to get this call more than
once a minute.
- Increase the time a service must run before we will reset its
restart delay to 30 minutes (from 10).
- Increase the restart delay multiplication factor from 2 to 4.
- Ensure that we don't restart more than one service every 10 seconds
(unless some external event causes a service's process to be started
for some other reason of course).
- Increase the amount of time that a service must run before we
decide to lower it to a background process.
And some other things:
- Catch IllegalArgumentException in ViewRoot like we do for no
resources to avoid the system process crashing.
- Fix a number of places where we were missing breaks between the
activity manager's message dispatch func(!!).
- Fix reason printed for processes in the background.
- Print the list of processing waiting to GC.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| de42bb61ad0e4947a38bdedfba6a20b5292025c3 |
|
05-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #2030135: Device sluggish
This adds some new debugging code to make it easier to see why a process is at
a certain oom_adj level -- for example telling you that a certain other process
has a binding to a certain one of its services. This has helped a lot in
identifying cases where processes are holding references to other processes that
they don't need and thus not allowing the system to get memory it needs.
Also fix a few problems with leaking entries on the service restarting and
service stopping lists.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 06de2ea752171f52a4e6e6872cb3a0689e591dcb |
|
21-May-2009 |
Dianne Hackborn <hackbod@google.com> |
Activity Manager changes the scheduling group of processes.
The algorithm for this is currently very simple: all persistent processes are
always in the normal scheduling group, all other processes are normal if their
oom_adj is as good or better than VISIBLE, otherwise they are in the background
group.
Note that this currently results in a fair number of log messages about not
being able to change the group, since the system process does not have
permission to do so. Once a kernel fix is in, these will go away and the code
will start working.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f5b9c72022f574417862e064cc0fdd8ea2d846dc |
|
18-May-2009 |
Jacek Surazski <jaceks@google.com> |
ActivityManagerService sends bug reports on crashes and ANRs
If an installerPackageName was specified when the app was installed,
looks for a receiver of ACTION_APP_ERROR in that package. If found,
this is the bug report receiver and the crash/ANR dialog will get a
"Report" button. If pressed, a bug report will be delivered.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 1655be46d2b7d45f071a6a1411ac8bd41c749c21 |
|
08-May-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #1837610 and #1753079
Issue 1837610 Adding a Widget before Running the Associated App Causes a Force Close
We were not retrieving the shared libraries of an application when deliving a
broadcast to an explicit component.
Issue 1753079 loading class path of instrumented app into instrumentation may load wrong path when instrumented app shares process with other apps:
We were using the ApplicationInfo that was used to originally create the process, not the one that the
instrumentation is against.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 1d442e0d990b581357f33f5463c7c5cb49b551e8 |
|
21-Apr-2009 |
Dianne Hackborn <hackbod@google.com> |
More optimization of dumpsys output.
There are three major classes of changes here:
- Avoid writing lines where their values are often empty, false, or some other typical thing.
- Use partial writes to the PrintWriter to avoid creating temporary strings.
- Use StringBuilder where we need to generate real String objects (and where possible cache the result).
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f210d6b75e2c0fe60b90c074ff9f615c1137f23e |
|
14-Apr-2009 |
Dianne Hackborn <hackbod@google.com> |
Let's do bug #1769910 actually right.
My original implementation was computing averages and medians. Now we do binning, as requested. So much simpler, too! In addition, it fixes a bug where when hoping across activities we were only accounting for the last activity as the total time; now we count the time from the start of the initial activity.
This also includes some reduction and optimization of the activity manager dumpsys output.
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| f013e1afd1e68af5e3b868c26a653bbfb39538f8 |
|
18-Dec-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Code drop from //branches/cupcake/...@124589
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/services/java/com/android/server/am/ProcessRecord.java
|