| fef10a47a810f375f762e77240718774a5f518aa |
|
13-Apr-2018 |
Tim Murray <timmurray@google.com> |
ActivityManagerService: add restricted cpuset
Test: CTS
bug 78197570
Change-Id: I9dd8daba6426b42b7e7e9388dbdac7bd8110b6ca
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| ed0a3220ceaf344531a6ac948a7aff9021fc8657 |
|
07-Feb-2018 |
Dianne Hackborn <hackbod@google.com> |
Further tuning of PSS collection.
We now keep track of a scaling factor of collection
for each memory state, and allow that to continually
grow as long as the process doesn't come back to it
from a new higher memory state. This should allow us
to spread out the sample rate for longer-running processes
to be much longer, to reduce the frequency of PSS
collection.
Also moved the decision about when to do a PSS sample of
all processes from some internal timing in the activity
manager to being tied to procstats data commits. This
makes the interval longer, and ensures after each commit
we have a good initial sample of memory data for all
processes.
Bug: 70859548
Test: atest CtsAppTestCases
Change-Id: Ia3ea2bc9e2d032d51e46e178e2b86b072af9f1ba
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| e17b445b6c813f6f9bc93a5e3811128a197ef50b |
|
10-Jan-2018 |
Dianne Hackborn <hackbod@google.com> |
Reduce pss collection amount, improve logging.
Tuned rates that we collect PSS, to reduce how much we do
that heavy operation. Added a new way to determine
whether a process has changed to a state for the
"first" time -- now this is when it has gone to that
state for the first time since it was in a lower state.
This will reduce the amount of time we consider a
process to be first to only when it has previously
gone into a higher state than it had before.
Keep track of more fine-grained information about why we
collect a PSS sample (not just internal, but for a single
process, all processes because of a mem state change, all
processes because of a poll).
Started collecting RSS in various places, so we can start
looking at that w.r.t. PSS and see about transitioning to
it is a new primary metric.
Added logging for many of the places where the system
writes its configuration files, so we can more easily
see any bad behavior going on in those areas.
Added some currently disabled code to read smaps directly
instead of using fgets(). Probably won't help, but want
tot test.
Bug: 70859548
Test: atest CtsAppTestCases
Change-Id: I400dba0f3ae9c024df51c946cfa592561028b598
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| db026a28aa56d725ef40e9f785d7582f6cd774b8 |
|
11-Jan-2018 |
Bookatz <bookatz@google.com> |
Update to the ActivityManager proto
Rename the activitymanager.proto to enums.proto, in accordance with the
new convention on naming these protos.
Also, changes processStateAmToProto from simplying multiplying by 100 to
a switch statement, to be more future-proof.
Also, changes the values of the proto's process state, to reflect that
the values will not be kept in sync with ActivityManager.
Note that this cl was originally started in ag/3008434, and partially fulfilled in ag/3114337.
Bug: 69478930
Test: run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.ProcStateAtomTests
Change-Id: I2b3bf2552b879c74d8985338df5a57c01850cb91
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 148d7f4291d675fc17852d530be32b7dba06fc93 |
|
28-Nov-2017 |
Yi Jin <jinyithu@google.com> |
Implement activity --proto --processes
Bug: 66729158
Test: out/host/linux-x86/bin/incident_report -w amprocesses
Change-Id: Iae043203bca954bfc4aadad0460cc56621e9ba05
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 10fc4fdd133c89347c38155475a3863bd12b94c4 |
|
20-Dec-2017 |
Dianne Hackborn <hackbod@google.com> |
Swap "foreground service" and "bound foreground service" proc states.
It has become apparent that apps running foreground services is
a much more important (and less common) state than all the various
ways apps run in the foreground because of the system being bound
to them or whatever else. So push this up about the bound foreground
service state, right after the explicit TOP state. Then we can
keep these together as "the app is explicitly running in the
foreground for some reason", etc.
Bug: 70808931
Test: CtsAppTestCases
Change-Id: Icfc1905b8e3eb60ddf26118c61ec1ef095659436
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 052e3149da48a8a841f5a974d60eb9d2109837de |
|
20-Dec-2017 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #70859548: Reduce amount of time spent collecting pss data
This slightly reduces the frequency we collect pss data, adjusting
some timings and adding back separate timings for when the device
is asleep. (Though note that the "same asleep" timings are currently
the same as "same awake," because those are already pretty infrequent.)
Also add some statistics to procstats to keep track of how many
pss samples have been taken, generally why, and how long they took
Bug: 70859548
Test: manual
Change-Id: If3c6cbd4ab045d2e4c00b48fe4257c4ec5ae3f33
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| bad8d91056e59b77fde1b2d3cc0745137766a31a |
|
19-Dec-2017 |
Dianne Hackborn <hackbod@google.com> |
Make TOP_SLEEPING procstate more like a cached process.
When an app is on the top of the activity stack but the screen
is not on, this doesn't really count as a top app in the normal
sense. In particular, we'd really like to apply the normal
restrictions we have on background and cached apps: no network
access, no ability to use wake locks, etc. (In other words, in
this state the app's activity is stopped, so from its perspective
it is no different than the user leaving it to go to another app.)
To do this, we change the order of the TOP_SLEEPING proc state
out from the range of foreground states down to between the
cached and background states.
Test: ActivityManagerProcessStateTest
Bug: 70808931
Change-Id: I994caba8c27553a452de75efa358be0e683d046f
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| f097d42f0c0a80a1c2d48f148346e6b0bf7a0f68 |
|
16-Dec-2017 |
Dianne Hackborn <hackbod@google.com> |
Move heavy-weight process state down to cached range.
This allows us to generally treat heavy-weight processes in
the background as cached processes, applying all of the limitations
we want for such things -- disable wake locks, etc.
Test: run-am-test ActivityManagerProcessStateTest
Bug: 63937884
Change-Id: I7c140c8f48188f6aa9c09731e83e3db4e4405e77
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| f6690100be5c5cd75c64d9a6a0345acff7b754d1 |
|
16-Oct-2017 |
Sudheer Shanka <sudheersai@google.com> |
Start processes asynchronously in AMS.
Currently, process start is initiated in ActivityManagerService
holding the main lock and this takes ~40ms to complete. As seen
in some of the issues in previous releases, this is one of the
contributors of the lock contention in system_server. This change
tries to address this issue by moving the process start outside
the locked section.
When a process start is required, instead of doing it synchronously,
this request will be posted on a handler thread. On the handler thread,
this process start request will be completed without holding a lock.
If for some reason, we decide the process is not needed anymore before
it is actually started or being started, then AMS does everything as
usual removing the references to the process from internal state except
actually killing the process which will be handled on the handler
thread.
Bug: 68775202
Test: Ran app startup perf tests using forrest, will update the bug with results.
Test: https://docs.google.com/spreadsheets/d/1cW81guRALZXKsN-WZsKyQiCSY-RgkJ2m_M9IfqIquz8
Test: cts-tradefed run singleCommand cts-dev -m CtsActivityManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWindowManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsMultiUserHostTestCases
Test: adb shell am instrument -e package com.android.server.am -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e class com.android.server.pm.UserManagerTest -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e package android.content -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: cts-tradefed run singleCommand cts-dev -m CtsProviderTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentResolverTest
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentProviderTest
Test: cts-tradefed run singleCommand cts-dev -m CtsWebkitTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideWebViewTests
Test: cts-tradefed run singleCommand cts-dev -m CtsAssistTestCases
Test: make WebViewLoadingTests && make tradefed-all && tradefed.sh \
run template/local_min --template:map test=WebViewLoadingTests
Test: adb shell setprop wrap.com.google.android.apps.maps \
'"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'
&& adb shell dumpsys meminfo --unreachable <PID_OF_APP>
&& check ppid of <APP> is logwrapper's pid.
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapNoDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapNoWrapTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugMallocDebugTestCases
Test: manual
Change-Id: I1fe7ce48cd5a4aadccaf6b3d6fdb5cad3304f1d3
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 352dc57186ff796dbb7a095c609d1a0bae5d3fca |
|
23-Sep-2017 |
Sudheer Shanka <sudheersai@google.com> |
Track some event history and include it in netpolicy dump.
Bug: 66921847
Test: manual
Change-Id: I0c473790f83076def807308fe44db9cb9365769e
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 68a0633ea9108e781cf74df89e48e6a727139bd8 |
|
16-Nov-2017 |
Dianne Hackborn <hackbod@google.com> |
Special handling of processes with recent tasks.
As the startup time of application processes has increased,
it is becoming more useful to try to keep around the process
for a recently used app, even if there are no longer any
actively running activities in it. (For example, if you backed
out of the root activity.)
This change implements that behavior, keeping track of any recent
task entries that a process represents the root activity for,
and classififying them under a new cached proc state that is
managed the same as a cached activity.
Test: manual
Bug: 69386069
Change-Id: I430741646478763fd85b33a5384278ece831b2c3
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| f4dd3711d1164ce6a442306615cac99119022215 |
|
12-May-2017 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #38242094: Activity manager oom adj computation seems broken
This shouldn't change any behavior, but improve the reason we
report for each process's oom_adj / proc state level. There are
two significant things going on here:
1. We now consider a bump up in proc state to be just as significant
as a change in oom_adj, and accordingly update the reason when this
happens. Given how many proc stats we now have mapped to some of
the single oom_adj levels, this matches your expectation to have the
reason be why it is at that proc state and not just some random
other thing at that level.
2. There is special handling of an app at the top state connecting
to another app, deciding the actual state to apply at the end. This
was not at that point updating the reason, so anything the top app
is connected to would get the top state but myseriously have some other
reason, looking very broken. We now propagate the reason over.
Test: manual
Change-Id: Idecbe206d73e7c4cbd989ef6faf3b1679e06c088
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 83b40f69bef4ba17bb63ac30d52f661a12d5b4f4 |
|
26-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #36891897: Need to ensure foreground services can't...
...hide themselves
The activity manager now keeps track of all apps that are running
foreground services and builds a notification showing them to the
user. We ensure they are shown to the user for at least 30 seconds
(configurable). If foreground services are executed while the
screen is off, their apps will be shown to the user for at least
30 seconds after the screen turns back on.
While doing this I am also adding a new process state to distinguish
between "important background" stuff that should bypass bg check vs.
ones that don't. By default, these now no longer bypass bg check,
which is really the expected (and documented) behavior. There is a
new bind flag to allow them to bypass bg check, which is currently
only used by the IME.
Also add some new job scheduler commands that will be used to
write new tests cases for jobs timing out.
Bug: 36891897
Test: manual
Change-Id: Ied3f7b56444254513fd776f06b88bc0e54704958
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 9484603c0fa738b67980c18b4abfd3505778ae74 |
|
01-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Framework support to improve bg check CTS tests.
(Finally) introduce a new ServiceConnection callback to
tell you when the binding has died. This allows you to robustly
have a weak service monitoring, and also is an easy way to find
out about breakages due to app updates etc.
Also clean up some debug output.
Test: moved to own suite and ran them.
Change-Id: I526cc00816c384fa9eb1312b92406f38085cbff9
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 0ef403e53e2762d077750dd0a50b73c2125cadb0 |
|
25-Jan-2017 |
Dianne Hackborn <hackbod@google.com> |
Add some new experiment constants for activity and power manager.
Activity manager now has constants, starting with two: bg check
and process limit.
Power manager now has constants, starting with one: controlling
disabling of wake locks from cached processes.
Test: manual
Change-Id: I05db42e2104e9d31584f85251412df2d5efb34b6
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 5614bf5a1ae4522dfc1a041f003cebc9b25c8b93 |
|
08-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Move code for handling uid obs "cutoff" to activity manager
To do this, I had to fix the PROCESS_STATE_NONEXISTENT constant
to be the last value (instead of the special magical -1 value)
so it semantically matches the public importance constants. I
think this is better anyway.
Also this fixes a big problem in the implementation, where we
weren't keeping track of the last proc state per uid...! Duh.
Test: manually ran testUidImportanceListener
Change-Id: Ie3008f824446089840f896885e6033472abb065e
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 1e32e025ad5677ce4e3697ca026c2019fe0bd8e9 |
|
17-Sep-2016 |
Andrii Kulian <akulian@google.com> |
Move updating stack override config to ActivityStack
Also added some multi-display TODOs.
Change-Id: Iada3f84c4f57c9623fc7f116819d4e0267ebc32a
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 33eb07f5759b85a5617f8057d8a335019c7d24dd |
|
10-Jun-2016 |
Tim Murray <timmurray@google.com> |
Add new mode for SCHED_FIFO on UI and RenderThreads.
Add a new mode, controlled by sys.use_fifo_ui property, that enables the
top app's UI and RenderThread to be SCHED_FIFO. This eliminates almost
all jank due to scheduling competition with non-UI critical
threads. This mode may not be suitable for all devices.
bug 24503801
Change-Id: I7b8a31830ad80f7efa00236928d5476998ed4e00
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| a49ad09c6f772fdbf829f85a6977fcde243c2b98 |
|
03-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #27381069: Master tracking bug: NYC is Sluggish
Have the activity manager us its own scheduling priority constants,
so that the new relative comparisons it is doing will work out
correctly.
Change-Id: I7bd1e5a3178ea491117bc497f87e4b75c92e0bc8
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| fdcc4d4235c829a41b4d23043431bb8fa915a440 |
|
15-Oct-2015 |
Chong Zhang <chz@google.com> |
Assign different oom score to visible apps based on layer ordering.
Pass oom score in kernel's full range [-1000,1000] to lmkd directly
bug: 21411311
Change-Id: I0cab2aa46269a716ea613025d3b84fe7d04404bb
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| ab4bb9d1fec685dab0fce9232c9a3477fab356b3 |
|
06-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21571700: Need to be smarter about how foreground...
...services get out of app idle
Introduce a new process state to even better distinguish foreground
services from other states. Rework the INTERACTION reporting to
usage stats to do it less when the screen is off -- require that
an app sit in the foreground service or top activity state for
at least 30 minutes before we consider it an interaction.
Also eradicate a bunch of logging in package manager.
Change-Id: I94249e67f9a9c62e9a92ae104710e6747b16327e
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 4870e9d5eba59fb257a87f97f1adf0b734cf48d3 |
|
09-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
More work on device idle mode and other power stuff.
Add idle mode support to the alarm manager. Introduce
a new concept of flags associated with alarms to tell
the alarm manager how to treat the alarm -- they allow
everything from the alarm that will bring us out of idle
mode, to alarms that are allowed when idle or should
also bring us out of idle. The standalone boolean is
now also a flag.
(Note there is currently no protection from user space
setting the flags however it wants; I will be working
on that in a follow-up change.)
When in idle mode, the alarm manager pushes all alarms
that shouldn't execute during that time over to a
separate list that is not executed until out of idle.
To help with this, I reworked a bit how Alarm objects
are managed, so that when rebatching or moving between
lists we don't have to allocated new objects but can
just use the same existing instance.
Also tweaked the sync manager to deal with idle mode,
which currently just means doing the same thing as when
low on storage -- turning off sync.
Add new ACTION_CHARGING and ACTION_DISCHARGING broadcasts
that apps can listen for to know when the device is actively
charging and discharging. These are better than the old
POWER_CONNECTED and POWER_DISCONNECTED ones because we only
report charging when we actually see that there is enough
power being provided to charge the battery (and will report
discharging if there is not enough power).
The job controller uses these new actions for scheduling
jobs that want to run while plugged in. Removed the
"stable charging" stuff while doing so, since the new
charging state serves as an even better signal for that.
Introduced two new process states: FOREGROUND_SERVICE and
TOP_SLEEPING. This will allow us to treat foreground services
specially (such as still allowing network access to them for
background music playback) while not mixing them together with
whatever happens to be the top activity while the device is
asleep.
Also some other small cleanup here and there.
Change-Id: I7a9808b578bad6f50deb8e1baf919298512a0d3a
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| e23149f1555303940d212b742707518b7f9f84ab |
|
07-Mar-2015 |
Wale Ogunwale <ogunwale@google.com> |
Converted some AMS log points to use ActivityManagerDebugConfig.
Change-Id: I0563bafd29ae0bbe596ed8c06fcc573b5ead50b7
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| c478cf5185337dcc2c54a074cf194d2d83689021 |
|
06-Jan-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #18907544: Activity manager miscomputed high RAM for 64 bit
No longer modify the base constants when computing oom adj values.
Change-Id: I1fa1e0013d544ad026de6dffecc7598ef7399911
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| e207ffe01d3e9185f2cac9501354a5236abcedad |
|
10-Dec-2014 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #18683980: questions on LMK memory changes" into lmp-mr1-dev
|
| ae6cc8af2674909924fb18cb73763a110bee63dd |
|
10-Dec-2014 |
Dianne Hackborn <hackbod@google.com> |
Further work on issue #18640385: Add procstats test mode
Tune sampling periods:
- Lower minimum sample interval when in test mode.
- Add a check when sampling pss to make sure this is at least 1
second since the pss changed, to reduce the amount of bad
data (very small pss samples) that we see.
Change-Id: I624a7d0480f3f6b22d229744e028d13a2c7b0e89
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 6466126ab0ac219229dfa3f5396cc03e9338b03b |
|
10-Dec-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #18683980: questions on LMK memory changes
Getting the denominator right is kind of important.
Change-Id: Iff02a0a95eccd1231042e4ea96011c8cee0fee02
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 1a4b5a4f02e7d8ff8ff645377d97e6062d36aeaa |
|
09-Dec-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #18640385: Add procstats test mode
You can now do "adb shell dumpsys procstats --start-testing" to
enable high frequency pss sampling.
Also improved the low on RAM mem reporting to separate out RAM
from memtrack, in case the data we are getting from that is bad.
And fixed meminfo --oom to work correctly again.
Change-Id: I7af17eab110a82298bd7b0ce381f8fa5c96c1f6a
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 824aeab2db793e4d7af9a30f5a38d6ca4d1606bc |
|
26-Nov-2014 |
Dianne Hackborn <hackbod@google.com> |
Re-tune low memory killer params.
Drop the minimums back down to their old values.
Revert what I think was a mistake in bumping up the last two
maximums to the same value as was being forced for 64 bit.
Smarten the 64 bit adjustment to be relative to the values picked,
rather than hard-coded.
Change-Id: Ibee9625073469ad4722a1b6684c9fb2b9f0a4681
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 423c44dc9186bcf3e825a9876233e36f8e9121e3 |
|
04-Nov-2014 |
Andres Morales <anmorales@google.com> |
[DO NOT MERGE] Increase min free levels for cached processes on 64bit
Requires less memory pressure to start killing cached
processes.
Change-Id: Ia02f5aee115535badc900330b9361f0099203e4f
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| ce09f5a53c8408d995c116a4430c000574d9875a |
|
11-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17829949: Don't kill Bluetooth service...
...even in extreme low memory condition
Bind to Bluetooth with BIND_IMPORTANT, so that it is allowed to
go to a higher oom adj level.
Fix some problems when this is done from a system or persistent
process, where this would go to a level that is *too* high. Instead,
introduce a new oom adj level for it that is right below persistent.
Change-Id: I002bcc4accc36c8579c4cda161be7d2fba21ba17
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 3f16dd49e8fe33f64d290a41ad1cb32c8a333ce6 |
|
03-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #17449495: Nakasi is pretty laggy/slow to do anything
Tweak the oom tuning to raise everything by 50%. This is the same
increase we did for Volantis; I am thinking that most of the issue
there was not it being 64 bit, but it being tighter on RAM. From
my testing, it looks like in user switching there was some paging
going on with Nakasi, and with this change things seem to be better.
We should probably revisit this for future work on RAM. It seems
likely that a 64 bit device will need more RAM, so probably the value
I am picking here is larger than we actually need for other devices.
I think this is the safest change at this point though -- it leaves
Volantis the same, where we already had tweaked it to address paging
issues, raises it on Nakasi (to the same value as Volantis) where we
seem to have paging issues, and on our other devices also raises it
but those are generally not under memory pressure so this shouldn't
really make a difference.
Change-Id: Ib19394068734d322a015ed07370d9d4961877e4b
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 465fa3963534e41ead0dce1273b71fd50c58c973 |
|
14-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #16907799: Processes containing bound services...
...are killed over eagerly.
When the current foreground activity is moving to the background,
it was briefly going through the CACHED_ACTIVITY state before the
correct LAST_ACTIVITY state, allowing its bound service processes
to be killed (because they went in to the cached list). To solve
this, as long as a process has stopping activities, it won't go
lower than LAST_ACTIVITY.
Also fixed a problem where we could put a process in CACHED_EMPTY
instead of CACHED_ACTIVITY_CLIENT. There were a number of cases
in the binding flow and also the client process state transitions
where we would not correctly updateing the bound client activity
state.
And add some sanity code so that if a process hosting a
service is killed, and a client process of that service is in the
cached state, we kill the client process. This avoids situations
where we can start thrashing around in the cached list because we
are restarting process for no reason -- since they will just
continue to be cached.
Finally, tune the process LRU list to allow twice as many cached
activity processes (from 8 to 16), so we can make better use of
the RAM we have available these days.
Change-Id: Ib0cdf78c321cbb035259fc9dd6ee27b5ba1f90c5
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 9d52f791b94bbf03739bdee4ccdd3ecb514c8eeb |
|
12-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17377423: Frequently see 500ms latency on app open...
...even for apps in cache
64 bit devices are cool, so they get to use more RAM for their
caches.
Shhhh, don't tell 32 bit devices, they get terribly jealous.
Change-Id: Iec9a0c43718a75530555bac50185658a682969aa
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| ecf1cda068c95c58d296d508d34706d659e4a1ae |
|
29-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Debug issue #17310019: pause when launching settings
Let's log!
Change-Id: Icaf42d46aff6e74ee5fc98611dd77083a5d5052e
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| d908edd810dd22d8ec512a19c32637df464e9d0a |
|
13-Jun-2014 |
Colin Cross <ccross@android.com> |
ActivityManager: pass the main uid of the app to lmkd
The uid and pid will be used to together to find any forked processes
and kill them.
Bug: 15313911
Change-Id: I2edb51527e5d1a977c0fad0e6c959c8438bb4be9
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|
| 49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/am/ProcessList.java
|