| 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
|