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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.java
|
786b44046a79d6c4c9cd07f5989d491c7196ad80 |
|
28-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix installing applications from non-primary users. We also now send the correct broadcasts to each user. You no longer need to be running the shell as root to be able to create/remove users. Also added some more man page material to the pm command, and got rid of a bunch of showUsage() calls that now make error messages completely buried because of how large the usage info has become. And the package manager now shows the user each historical broadcast was sent to. Change-Id: Iab42498e1352a0c023069139c80fc04d2d69ab4b
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.java
|
f46723b41f723ebfc9ed18c7c409b319f4b5e539 |
|
26-Jan-2012 |
Christopher Tate <ctate@google.com> |
Implement background vs foreground broadcasts Before now, receiving a broadcast would cause a process to be hoisted to foreground priority / cgroup. This is no longer the case: broadcasts by default are handled in the background, with a suitably increased timeout interval. When a given broadcast needs to be dealt with in a more timely manner, the issuer can set the new FLAG_BROADCAST_FOREGROUND flag on the Intent, which will produce the old foreground-priority behavior. To avoid priority inversions, foreground broadcasts are tracked on a separate outgoing queue and can be in flight simultaneously with a background-priority broadcast. If there is already a background-level broadcast in flight to a given app and then a foreground-level one is dispatched to that app, the app [and its handling of both broadcasts] will be properly hoisted to foreground priority. This change is also essentially the first step towards refactoring the broadcast-handling portions of the Activity Manager into a more independent existence. Making BroadcastQueue a top-level class and regularizing its operation viz the primary Activity Manager operation is the next step. Change-Id: If1be33156dc22dcce318edbb5846b08df8e7bed5
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
d99b293d5f11b784d7406f5398bc654920b42482 |
|
18-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5180553: permission RECEIVE_BOOT_COMPLETED is not checked Change-Id: I069673f2fbdf05e409c5e9ed99ccd1e15b4fe3ed
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
b5a8654dea9ea8443b41f8ff3668ae4074e13a07 |
|
27-Oct-2010 |
Johannes Carlsson <johannes.carlsson.x@sonyericsson.com> |
Clear reference to the IIntentReceiver in order to avoid memory leak When using sendOrderedBroadcast(..) with a BroadcastReceiver the BroadcastReceiver instance was not released. The reason for this was that the resultTo field in the BroadcastRecord kept a reference until it was pushed out of the mBroadcastHistory. This reference in turn kept a reference to the process side IIntentReceiver (implemented in ReceiverDispatcher$InnerReceiver). This in turn had a strong reference (through mStrongRef) to the Context. In order to keep the debug output the resultTo is also kept as a String in the new resultToString variable. Change-Id: I4382a22a541c27b3694fb2b78a04ee820b235f8f
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
043fcd9847a804bc6394728e5785aecc495e6347 |
|
06-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #3062691: GPS enable bypass via com.android.settings.widget.SettingsAppWidgetProvider Exposes an Intent I need (okay it fixes an unrelated thing in the power widget), and fixes some dump output. Change-Id: I51d6c93a6ac879bab64e9d5aa21129e2bbcd461b
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.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/BroadcastRecord.java
|
399cccb85749e02f6d3e12d1d2846310e7cbfdf1 |
|
14-Apr-2010 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #593153: Broadcast time out when sending... ...ordered broadcast for ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE Turns out this was because the broadcast receiver for ContextImpl was not correctly being created, so when it received an ordered broadcast it would not tell the activity manager when it was done. This is now fixed, along with a ton of superficial changes to debug output to help track this down and a little cleanup of dealing with error cases in dispatching broadcasts. Also a fix for a NPE when dumping the broadcast state. Finally, a little fiddling with package manager to get rid of a lot of the noise when removing and re-adding packages on the SD card. Change-Id: I961c14836dc613d3ea8122b6e910ef866e7fcb25
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
12527f9fb1cb0a1ad3be8149c1c88a0e731cb4d6 |
|
12-Nov-2009 |
Dianne Hackborn <hackbod@google.com> |
Debugging for issue #2250075: Desk dock clock app sometimes doesn't This adds a history of the last 100 broadcasts that is printed in the debug log, to be able to see what recently happened at the time the bug report was taken. Also does some optimization of the printing of the broadcast records to make it feasible to print this number of entries. (We kind-of need to do this because there are some broadcasts like SIG_STR and SYNC_STATE_CHANGED that are being broadcast a LOT.) Change-Id: I775e1ec0f63369c8bca8c83cee27b95ddc5ec450
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
68d881cf2d2b252f6f795cd64d43e316a1d736e5 |
|
05-Oct-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2166755: BroadcastReceiver trying to return result during a non-ordered broadcast Tell the broadcast receiver whether it is getting an initial sticky value, so it will be quiet about attempts to do ordered broadcast stuff. Note that the original bug being reported was not actually a crash, just an error log. So all we are doing here is making the log quieter. Change-Id: Iaf1b718d82093ec1197142410a64feff47eb3859
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|
1ccac75e1f1b97eccb916a8de04fc1012b30f6e5 |
|
12-Jun-2009 |
Suchi Amalapurapu <asuchitra@google.com> |
Remove circular dependency in PackageManager. api freeStorage uses PendingIntent from android.app Create a new public IntentSender class that can be used by PackageManager instead. This new class uses IIntentSender internally and can only be created by PendingIntent for now. Provide a new getIntentSender api in PendingIntent to create an instance of this class. Move IIntentSender and IIntentReceiver from android.app to android.content Change imports of IIntentSender and IIntentReceiver to reflect the new package name The PackageManager api has been named as freeStorageWithIntent and will be renamed as freeStorage once the older api(which has been deprecated) will be removed shortly.
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.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/BroadcastRecord.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/BroadcastRecord.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/services/java/com/android/server/am/BroadcastRecord.java
|