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