ba629da331d01d74067afdda5d4255682d4b24d7 |
|
14-Nov-2013 |
Christopher Tate <ctate@google.com> |
Ensure recipient can be launched before attempting broadcast delivery User removal or eviction inherently races with broadcast delivery. This patch introduces a latest-possible recheck of the availbility of the target application before attempting to send it a broadcast. Once the process has actually been spun up the system is essentially committed to presenting it as a running application, and there is no later check of the availability of the app: the failure mode for continuing to attempt delivery is a crash *in the app process*, and is user-visible. We now check the app+userid existence of the intended recipient just prior to committing to launch its process for receipt, and if it is no longer available we simply skip that receiver and continue normally. Bug 11652784 Bug 11272019 Bug 8263020 Change-Id: Ib19ba2af493250890db7371c1a9f853772db1af0
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
db92608de9b4acccee1e3232264c9830ad300c4f |
|
01-Nov-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11168649: LRU logic for Chrome renderers seems... ...not to work on KitKat (was: Janky exit animation) Reworking the LRU list (splitting it into an activity vs. empty section) accidentally broken the old behavior of "client activity" processes being prioritized with activity processes. In fact, we were no longer marking "client activity" processes at all. In this change, we rework how we manage "client activity" processes by putting them on the main activity LRU section. This is generally simple -- ActiveServices now keeps track of whether a process is a "client activity" process based on its bindings, and updateLruProcess treats these as regular activity processes. However, we don't want to allow processes doing this to spam our LRU list so that we lose everything else, so there is some additional complexity in managing that list where we spread client activity processes across is so that the intermingle with other activity processes. The rest of the change is fairly simple -- the old client activity process management is gone, but that doesn't matter because it wasn't actually running any more. There is a new argument to updateLruProcess to indicate a client process it comes from (since we now need to update this based on bindings) which is just used to limit how high in the LRU list we can move things. The ProcessRecord.hasActivities field is simply removied, because ProcessRecord.activities.size() > 0 means the same thing, and that is actually what all of the key mechanisms are using at this point. Finally, note there is some commented out code of a new way to manage the LRU movement. This isn't in use, but something I would like to move to in the next release so it is staying there for now for further development. Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
4c51de493308eab0ffd17529f8a1aab29dbba68a |
|
17-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Increase size of broadcast history lists on non-svelte devices. Change-Id: Ibd25379778dac8eb1aed30d4788e032f290d9b69
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
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/BroadcastQueue.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/BroadcastQueue.java
|
6285a32f74890b761579b4f67afde1b08763fd0a |
|
18-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Finish issue #10779747: Calendar Storage crash observed... ...while setting up a new user from settings. We can now delay broadcasts when there are enough background services currently starting (still set to 1 for svelte devices, 3 for normal devices). Add new intent flag to not allow receivers to abort broadcasts, which I use to fix an issue with the initial BOOT_COMPLETED broadcast not actually requesting pss data at the right time -- it can now be sent as an ordered broadcast without the ability for the receivers to cancel it. Change-Id: I51155bbbabe23e187003f3e2abd7b754e55d3c95
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
49660c7c24f24c3394233e3bbf94c96281e8c408 |
|
07-Aug-2013 |
Ben Gruver <bgruv@google.com> |
Add support for broadcast intents Change-Id: Icf61e7a202f489cb33b9fd95564285e48154b25b
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.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/BroadcastQueue.java
|
1304f4ae32cf7121fe11e95f2a7151ea208b6cca |
|
10-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new location monitoring op, make some of app ops public. The new location monitoring op is to tell us when an application is monitoring for any location changes. It may be useful information in addition to the more explicitly information about when location data actually goes to the app. Also make parts of AppOpsManager public for use by gcore. It is not available to third party apps. Change-Id: Ib639f704258ffdd7f3acd7567350ed2539da628a
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.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/BroadcastQueue.java
|
a40cfeb55f6caa35fee894b86175b7d916520c80 |
|
26-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #8470131: Process thrash kills battery Protect app widget broadcasts from abuse. In this case the app was sending an APPWIDGET_UPDATE broadcast without specifying a target, which (a) should not be allowed (you should not be able to send updates to other apps), and (b) resulted in every single potential app widget in the system being launched... which was about 75 of them. Change-Id: I9d48733610ce6d5a7c32e69a3e06b9f33bd79a34
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
f51f61269aacdfcf737b2c32b6b216c48ab61e65 |
|
05-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: new operations for SMS. Implementation required a new framework feature to associate an app op with a broadcast. Change-Id: I4ff41a52f7ad4ee8fd80cbf7b394f04d6c4315b3
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
6c5406acd72eed31f2b4e12f5eddc0e2d2a951e2 |
|
30-Nov-2012 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #7596986: Frequent runtime restarts; IAE at... ...android.os.Parcel.nativeAppendFrom(Native Method) The failing stack trace is: 11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.nativeAppendFrom(Native Method) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.appendFrom(Parcel.java:428) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1613) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.content.Intent.writeToParcel(Intent.java:6660) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230) 11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777) This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel we have with its current length. There is no way this should be able to fail like this... unless the Bundle is changed while we are running? Hm. It looks like the location manager is holding on to Location objects which have a Bundle of extras. It is that Bundle of extras that the crash is happening on. And the bundle extras can be changed as it operates. And there are places where the raw Location object is returned from the location manager, which means the caller can be olding on to a Location object whose extras can be changed at any time by other threads in the location manager. So that seem suspicious. This change should take care of all these places in the location manager, by making sure to copy the location object before it goes out of the location manager. In addition, add some code to the activity manager to not bring down the entire system if there is a problem trying to send one of these broadcasts. There is no need, we can just skip the broadcast as bad. Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
c0bd747b0605af251ff136277f14220a5a4c9818 |
|
09-Oct-2012 |
Dianne Hackborn <hackbod@google.com> |
Further work on issue #7307399: Framework needs a new pre-user-shutdown... ...phase & callback API I realized there were a few things wrong with what was there. The new ACTION_USER_STARTING was not being sent for the first user at boot, and there was an existing problem where ACTION_USER_STARTED was sent every time there was a user switch. Also improved some debug output of broadcasts to make it easier to see what is going on in this stuff, and better reporting of why a service couldn't be started. Change-Id: Id8a536defbbad1f73d94a37d13762436b822fbe3
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.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/BroadcastQueue.java
|
6cbd33fc25fa48dcb673edc150d2315bec4ade3a |
|
18-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix dumb bug merging receivers for multiple users. Also clean up some debug output. Change-Id: Ib19e47682e9ddfc6a234bd61d054275a362d28cc
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
20e809870d8ac1e5b848f2daf51b2272ef89bdfc |
|
01-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Add registering for explicit users. New API to register as an explicit user, which allows you to also select ALL to see broadcasts for all users. New BroadcastReceiver API to find out which user the broadcast was sent to. Use this in app widget service to handle per-user package broadcasts and boot completed broadcasts correctly. Change-Id: Ibbe28993bd4aa93900c79e412026c27863019eb8
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
8bf06edac2088ad100e67dcb00a46d3f0f95c126 |
|
28-Aug-2012 |
Amith Yamasani <yamasani@google.com> |
Relax permission requirement for sending broadcasts to other users Also handle USER_CURRENT for broadcasts Change-Id: I2df5616ac22b7c670a7d007b8d505d4d4d99a24e
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
7d19e0242faac8017033dabb872cdf1542fa184c |
|
08-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
More mult-user API work. - You can now use android:singleUser with receivers and providers. - New API to send ordered broadcasts as a user. - New Process.myUserHandle() API. For now I am trying out "user handle" as the name for the numbers representing users. Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
b4163a6e12ee7100c758c6d3d062ade1f2843fce |
|
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Add APIs for interacting across users. - Expose the existing Context.sendBroadcast() as Context.sendBroadcastAsUser(). - Add new android:singleUser attribute for services. - Add new INTERACT_ACROSS_USERS_FULL permission for full system-level access to cross-user interface (allows sendBroadcastAsUser() to send to any receiver). - Add new INTERACT_ACROSS_USERS_FULL permission for more restricted cross-user interaction: this is required for android:singleUser, and allows you to use sendBroadcastAsUser() but only to send to your own receivers. Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
a4a54e2a5f383e766bfecaec776e0b00002badd1 |
|
17-Apr-2012 |
Amith Yamasani <yamasani@google.com> |
Make sure persistent processes are not replicated for secondary users. An intent is launched in a singleton process if the process is persistent and the resolved activity/service/etc is not requested to run in a different process. Change-Id: I1463e73a76bc8bde4185f9cf4395edb47515841d
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
483f3b06ea84440a082e21b68ec2c2e54046f5a6 |
|
14-Mar-2012 |
Amith Yamasani <yamasani@google.com> |
Package restrictions per user Packages can be enabled/disabled per user. This requires maintaining stopped/launched states and enabled / disabled components and packages per user. Refactored pm.Settings and PackageSettingsBase to keep track of states per user. Migrated the stopped-packages.xml to users/<u>/package-restrictions.xml Changed intent resolution to handle individual user restrictions. Bunch of IPackageManager calls now have a userId argument. Make AppWidgetService handle removals of packages. Added some tests for pm.Settings and PackageManager. Change-Id: Ia83b529e1df88dbcb3bd55ebfc952a6e9b20e861
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|
40c8db5a28e9abae2033facce1354e3677911fcc |
|
11-Feb-2012 |
Dianne Hackborn <hackbod@google.com> |
Move BroadcastQueue out of the ActivityManager class. Change-Id: Ib468481588a1aa506ff00f3c4b1a6ecf672c7b99
/frameworks/base/services/java/com/android/server/am/BroadcastQueue.java
|