| 878deb3c7b33a0c508137143c776e07bab0296cf |
|
15-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11223335: APR: Lots of failures in procstats due to...
...bad cleanup of crashing processes
We now have a special path for crashing processes, to silently
clean up their state.
Also some tweaks to Log/Slog.wtf to get better stack crawl
summaries in APR.
Change-Id: Ieced26989907a6e7615b6fa033813fced78d7474
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 164371fb759bad6854570af0fca60d9a01e17235 |
|
02-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11005453: [SUW] G+ profile creation for new user broken
The main problem here was a mistake when turning a single process
structure to a multi-package-process structure with a common
process. When we cloned the original process state, if there were
any services already created for the process for that package, they
would be left with their process pointer still referencing the
original now common process instead of the package-specific process,
allowing the active counts to get bad. Now we switch any of those
processes over to the new package-specific process.
There was also another smaller issue with how ServiceRecord is
associated with a ServiceState -- we could be waiting for an
old ServiceRecord to be destroyed while at the same time creating
a new ServiceRecord for that same service class. These would share
the same ServiceState, so when the old record finally finished
destroying itself it would trample over whatever the new service
is doing.
This is fixed by changing the model to instead of using an "active"
reference count, we have an object identifying the current owner
of the ServiceState. Then when the old ServiceRecord is cleaning
up, we know if it is still the owner at that point.
Also some other small things along the way -- new Log.wtfStack()
method that is convenient, new suite of Slog.wtf methods, fixed
some services to use Slog.wtf when catching exceptions being
returned to the caller so that we actually know about them.
Change-Id: I75674ce38050b6423fd3c6f43d1be172b470741f
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 2be00933163bb2bfa6b43cf2e1ddde7c284c7c4c |
|
23-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Debug issue #10876433 java.lang.IllegalStateException...
...in ActivityManagerService.updateLruProcessInternalLocked on bluetooth
Add more debug output to help track down what is going on.
Also fix a little problem where, when a service ANRs, if you ask to
wait and it still wasn't responding, the ANR dialog wouldn't be
shown again.
Change-Id: I5be2b1705a0a39ca2992624ae683945c5f38065d
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.java
|
| bd754f44cd8a39bd2298e0d6496c50b79162fb90 |
|
24-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix bug that was causing us to lose total memory buckets.
When safely resetting stats after committing them, we were
mistakenly clearing the current memory state so we would lose
that total memory time until the memory state changes again.
Also improve the summary output to print percentages, which
make more sense for that display.
Change-Id: I0fe45fd78e97ec8b94976170dd42f4ed345a5899
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 91268cf21eace600792d04db1ac62e9268f48002 |
|
14-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
More work on process tracking.
Re-arranged code to be more flexible, now track
state of services, dump ordered list of running
processes while memory was critical and low.
Also rename battery stats service from "batteryinfo" to "batterystats".
Change-Id: I0f4f0c8d443c49d255cb84d0fc917e8ec18b152e
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.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/ServiceRecord.java
|
| ca92a4c38f8b4763cd72690091b3a5bbbd7c973a |
|
03-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8798662: NPE in...
...com.android.server.am.ServiceRecord.postNotification()
Change-Id: I3403bc50eb95d410183fc60ef252775a688b6290
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 91fe8455d66ef4ac000ba3ba0fb043dd1fbaee49 |
|
08-Apr-2013 |
Daniel Sandler <dsandler@android.com> |
Clean up language in forced foreground service notifications.
Old: [ IC ] %s running
[ ON ] %s is running
New: [ IC ] %s is running
[ ON ] Touch for more information or to stop the app.
Additionally, disallow these misbehaving services from
supplying their own content views; if you attempt to run a
foreground service with icon == 0, this is the notification
you will get, period.
Bug: 8525548
Change-Id: I2bfd7340396ef925885e8c2160a720f9eff07a35
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 2ced96c54445efca6522afd1878f79c9ee2780ba |
|
21-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8436951 JB-MR2: Compatibility: Audible, Pandora, ...
...Tune-In does not work since JWQ77
Instead of crashing the app for it being bad, just go ahead and
show a notification for it anyway that we make up.
You get what you deserve. :p
Change-Id: I92e32b9ff8835dabde63f8e08e991f72de0d0a92
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 282add7bc3e80825c73244f527857aefa74093a9 |
|
16-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8401553: It's possible to startForeground()...
...with no visible Notification
Don't allow a 0 icon resource.
Change-Id: I52e93533e6c45c6027ff3c185060cd54d087d077
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| f265ea9d8307282ff1da3915978625a94fc2859e |
|
01-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: vibration, neighboring cells, dialing, etc.
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.java
|
| 4120375d46091df8527bb701882e056fbb0e6b06 |
|
31-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Remove Binder.getOrigCallingUid().
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 0c3804950236fe170ebf6cc7a5f1e3e305b8f315 |
|
21-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Improve multi-user app management.
Introduce API to get per-user storage information, keep track
of services associated with users, and various small cleanup.
Change-Id: I5d4e784e7ff3cccfed627d66a090d2f464202634
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.java
|
| 21c241e061de29a538008ca42df9c878184bcfb8 |
|
08-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new Intent API for associating a ClipData with an Intent.
Allows applications to propagate multiple URI grants through an
Intent.
Later on, we should probably redefine the share actions to be
based on this ClipData with the old extras-based approach only
there for compatibility. Even if we don't do that, though, this
allows you to do a multi-select share that grants multiple URI
permissions by stuffing the URIs in a ClipData.
Also add some documentation in various places telling people how
they can grant URI permissions.
Change-Id: Id4ba8e72c11caf7e1f1f438cb7af058d1586a37c
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.java
|
| 742a67127366c376fdf188ff99ba30b27d3bf90c |
|
04-May-2011 |
Amith Yamasani <yamasani@google.com> |
Multi-user - 1st major checkin
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 90c52de28691ca0bbbf7c039ef20f85ce46882cc |
|
23-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5173952: Opening a Notification From Lock Screen...
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| a301fe61c8573c06be754d5788a84d19188ee2d3 |
|
04-May-2011 |
Marco Nelissen <marcone@google.com> |
Fix dumpsys output.
Change-Id: If3f51fbc4608ac295fa22d0aee4008f8dce4fa50
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.java
|
| e17aeb31030cfeed339a39a107912ad5e9178390 |
|
08-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve activity manager debug dumps.
Activity manager now does all dump requests into apps
asynchronously, so it can nicely timeout if there is an
app problem. Also lots of general cleanup of the am
dump output.
Change-Id: Id0dbccffb217315aeb85c964e379833e6aa3f5af
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| eaa0718780a29df8fbe42c59beecee5557fdf785 |
|
24-Sep-2010 |
Joe Onorato <joeo@android.com> |
Crash apps when they provide bad notifications instead of crashing the system process.
Bug: 2958415
Change-Id: I9cbef340fb20a64eca8493950b814399c26ce197
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 7e269644fcc319835f1e7f762f3cbd8087e3e22f |
|
26-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Don't retain global ref to last inflated context.
Also rework URI permission granting to support upcoming
clipboard use.
Change-Id: I9842920350955531c5a511c2ecc5215e8c783343
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 43d9ac81f7722bb539ee67023f10b9f43abbf202 |
|
26-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix a fun bug with multiple service bindings from an activity.
There was a flaw in the service management, when the same activity
is doing a bindService() for the same service IBinder. In this case
the activity would correctly keep a list of all generated connections,
however some other data structures would assume there is only one
connection per IBinder, and thus only remember the last.
When that last connection was unbound, the service would be destroyed
since it thought there were no more connections. Then when the
activity was finished, it would try to destroy the service again and
end up with an ANR because the service was already gone and would
not respond.
Change-Id: I59bde38bc24e78147b90b0a7cd525c2a1d20489f
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 39792d2262352ae775091876d5488d2412a2ff92 |
|
20-Aug-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix bugs with granting permissions through onNewIntent().
It would grant the permission to the temporary ActivityRecord,
not the real one, so it never got cleaned up.
Also allow granting of permissions to services because... well,
it would be really really useful. And it introduces some
refactoring that we'll need to support cut/paste.
Change-Id: If521f509042e7baad7f5dc9bec84b6ba0d90ba09
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.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/ServiceRecord.java
|
| d0a2f86f357f346639a6648b4004266865c979b4 |
|
03-Aug-2010 |
Daniel Sandler <dsandler@android.com> |
Fix crash when startForeground posts a broken Notification.
The NotificationManager tries to crash the calling app, but
in the case of a service calling startForeground, the caller
is the ActivityManager, so system_server goes down.
NotificationManagerService#enqueueNotificationInternal is a
new internal-only method that accepts a UID/PID to use when
punishing bogus notifications (such as the one in
http://b/2869787).
Change-Id: I84a9854bae630bc90288cebb94f174809d5dac8c
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 8a9b22056b13477f59df934928c00c58b5871c95 |
|
27-Feb-2010 |
Joe Onorato <joeo@android.com> |
Switch the services library to using the new Slog
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 9e0f5d9a63ba88c2bf69df0557f8c9696db370c4 |
|
23-Feb-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix some random bugs.
2185256: After open &close of device keyboard shortcut does not added to Home desktop.
ActivityThread was losing the last saved state when restarting or launching into
a paused state.
2366174: defaults not cleared when they should be
PackageManagerService now removes any preferred activity records for a package
when it is uninstalled.
2154556: Battery stats can have an unbounded number of wake locks
We now start combining wake locks into one shared record when we hit a
maximum limit (currently 20).
2442519: Foreground services can have no notification by providing a bogus one.
If the notification manager rejects our notification, the service is forced to
no longer be in the foreground.
2442383: Finalization issues in com.android.server.am.PendingIntentRecord.java
Cleaned up finalization to call super class and avoid the big activity manager
lock (we still need to use the locks inside of the message system, but these
are much less likely to be a problem).
2284190: Cannot call a phone number using adb
We weren't getting the calling uid/pid in startActivity() if the caller did not
supply an application record.
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 34fcf971037f33605e8009946d3acc686819dd6d |
|
18-Feb-2010 |
Joe Onorato <joeo@android.com> |
Don't crash the system process when apps give us a bad foreground service notification.
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| b1c4a2a3b37fccf68e6a9563cccf1685df2bf3e7 |
|
20-Jan-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2364506: Phone locked up while listening to music and attempting to download an update
Make sure calls into the notification manager are not done with the
activity manager lock held.
Change-Id: Ib53c3b9f46160d94ee1e7079b1a5123e0d1225d8
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| 6ccd2aff3eb4450c6f1021637d18e4e5d9346bf0 |
|
27-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
resolved conflicts for merge of 301b97ac to eclair
Change-Id: I0fb70cbe0a52006ad14f43a02c30b72aad457c48
|
| 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/ServiceRecord.java
|
| f6f9f2d0256930ce0bb4913b2260b8480914edc2 |
|
22-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Add more control over a service's start state.
One of the problems I have been noticing is background services
sitting around running and using resources. Some times this is
due to the app developer doing this when they shouldn't, but there
are also a number of issues with the current Service interaction
model that make it very difficult (or impossible) to avoid
getting services stuck in the started state. This is a
change/enhancement to the Service API to try to address this.
The main change is that Service.onStart() has been deprecated,
replaced with a new Service.onStartCommand() that allows the
service to better control how the system should manage it. The
key part here is a new result code returned by the function, telling
the system what it should do with the service afterwards:
- START_STICKY is basically the same as the previous behavior,
where we usually leave the service running. The only difference
is that it if it gets restarted because its process is killed,
onStartCommand() will be called on the new service with a null
Intent instead of not being called at all.
- START_NOT_STICKY says that, upon returning to the system, if
its process is killed with no remaining start commands to
deliver, then the service will be stopped instead of restarted.
This makes a lot more sense for services that are intended to
only run while executing commands sent to them.
- START_REDELIVER_INTENT is like START_NOT_STICKY, except if
the service's process is killed before it calls stopSelf()
for a given intent, that intent will be re-delivered to it
until it completes (unless after 4 or more tries it still
can't complete, at which point we give up).
Change-Id: I978f5ca420d70023d1b5e7f97de639d09381f8ad
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|
| d8a43f61680bacf0d4b52a03ff3c7a07307377fc |
|
18-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2047139: Remove Service.setForeground()
This API is becoming seriously abused, so now it is deprecated and has
become a no-op.
As an alternative, there is now a new API that allows you to make a service
be in the foreground but requires providing a persistent notification to
go along with this state, allowing the user to know about and control it.
/frameworks/base/services/java/com/android/server/am/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.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/ServiceRecord.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/services/java/com/android/server/am/ServiceRecord.java
|