| 816c83bf037e2284a61ac8e918ff882d162d9321 |
|
02-Mar-2017 |
Chad Brubaker <cbrubaker@google.com> |
Enforce visibleToInstantApps for receivers
Instant apps can only send broadcasts to receivers that are declared in
the manifest with android:visibleToInstantApps=true or if the app
registers a receiver at runtime using the new methods that take
visibleToInstantApps.
Bug:33350280
Test: Manually sending broadcasts from Instant Apps only goes to
receivers with visibleToInstantApps set to true.
Test: Receiving a broadcast from within the same app does not require
visibleToInstantApps to be set.
Change-Id: I54d79a502ba9c5fd03ede3c09e08afc88fe2775f
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 448489a991773b58f4be4ef06553a8a0b235f78b |
|
29-Sep-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #29422027: APR: Runtime restarts in system_server
More debugability.
Change-Id: I93b8e2ac63a25ca43d0eaedfcf8262ba92bc15d5
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| bc02a3901dea52d236dd855722191155156cb856 |
|
03-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29006049: Add logging for implicit broadcasts
We now have stats on broadcasts. We collect them over a day and
then reset, retaining the last days stats. When a checkin happens,
we return either the last day or the current stats and then clear
them. Not bothing to persist anything to storage, this data is
not that critical.
Change-Id: I1c3b331bcd03f79fa5e10575d9bc2ad7d9104f6f
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| e0e413e2b17a0164e15c77f4ab51b3166f9111d2 |
|
10-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
Add new target SDK filtering feature to BroadcastOptions.
You can now control the range of target SDKs that receivers
will be need to have in order to receive your broadcast.
Use this for CONNECTIVITY_ACTION to not allow N+ applications
to receive these broadcasts through their manifest.
Also tweak the broadcast debug output code to now include the
disposition of each receiver in the list. This is becoming
important as skipping receivers is becoming a more common
thing to have happen.
Change-Id: I251daf68575c07cbb447536286ab4e68b7015148
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 6ac42aeed905181b484f97a53db57a17134ef7a8 |
|
09-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
Add a mechanism for broadcasts to control background dispatching.
Right now this is just for the BOOT_COMPLETED broadcast to allow
all apps to receive it.
Also clean up the dumpsys of the broadcast queue to not have
every little detail of ResolveInfo+ActivityInfo+ApplicationInfo,
which is just not useful and makes reading the broadcast queue
debug output a lot harder because of so much noise there is.
And rename the package shell query-intent-* commands to a
shorter query-* form.
Change-Id: I0d01565babb87e68b840c9756a2ea730d699efc7
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 865907db099eed08cac7ab177161361f5c82e656 |
|
22-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Hopefully fix issue #25153459: Sandboxed_process1 thrashing
There is a race where if you unbind to a service before its
process has come up, we would leave the service record active
and keep it running. Fix this by checking the service state
after its process up and proceed to bring it down if it is no
longer needed.
Also added a similar check when restarting a service, just in
case there are other ways we can get into this situation.
And while I am at it, I tweaked the broadcast queue dump output
a bit to hopefully make it a lot easier to figure out how long
it is taking to process broadcasts.
Change-Id: I46b98f1fe394ab8039ea4cc81fb5d3afb6391a31
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 9a6e13c347df85348db8c0af67eeaa558fd61ee9 |
|
04-Aug-2015 |
Wale Ogunwale <ogunwale@google.com> |
Set broadcast nextReceiver correctly when package is disabled
When we are cleaning up broadcat receivers due to a package been
disabled, it is possible to remove enough recievers to cause the
nextReceiver index to be greater than the size of recievers list.
We now set the nextReceiver to the size of the receiver list
(which means done processing) for this case.
Bug: 22874330
Change-Id: Ie151d1b5bff4c11533b3a8635fe5ee82eb21c13c
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| d4fd8c766da8a70e3359bbc7efbbc79496efe71a |
|
14-Jul-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Added sendBroadcastMultiplePermissions method
Added Context.sendBroadcastMultiplePermissions(Intent intent, String[]
receiverPermissions) method, which allows an array of required permissions
to be enforced.
Bug: 21852542
Change-Id: I27c9130e8f004b428452501ebc8a36aabde1f343
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| e37520b49da8fc2b7b7501c6dbbe1e6ac984dd9f |
|
15-Jul-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Revert "Allow array of required permissions in sendBroadcast"
This reverts commit b4e7283c9afd9fb15ebd63f6ce9b75c9c1af658b.
Change-Id: Ie8390964bda5bdfa869cee8f46584043d8e7c664
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| b4e7283c9afd9fb15ebd63f6ce9b75c9c1af658b |
|
14-Jul-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Allow array of required permissions in sendBroadcast
Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| a750a63d639f6936af456df904fa6b9ba941885e |
|
17-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21814207 and issue #21814212 (alarm manager)
Issue #21814207: AlarmManager.setAndAllowWhileIdle should also allow wake locks.
Introduce a whole new infrastructure for providing options when
sending broadcasts, much like ActivityOptions. There is a single
option right now, asking the activity manager to apply a tempory
whitelist to each receiver of the broadcast.
Issue #21814212: Need to allow configuration of alarm manager parameters
The various alarm manager timing configurations are not modifiable
through settings, much like DeviceIdleController. Also did a few
tweaks in the existing DeviceIdleController impl.
Change-Id: Ifd01013185acc4de668617b1e46e78e30ebed041
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| ca1c12581a794db7569c7408b3547bf04f9bb3c9 |
|
15-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Clean-up broadcast receivers when component is disabled.
Bug: 15804187
Change-Id: Ib672f720bd5c8d81d3846568ef53f7723685f317
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 9fb3fd1d666aac3e8d889bead4109690b1484aac |
|
30-Sep-2014 |
Jeff Brown <jeffbrown@google.com> |
To help assess latency, dump the time a broadcast was enqueued.
Previously we only dumped the time when a broadcast started dispatch.
Start tracking the time when a broadcast was enqueued so that
we can determine whether the broadcast queue was stalled and for
how long. Together with other information in the dump, this can help
to ascertain whether broadcast latency is being caused by the sender,
the dispatcher, or the receiver.
Bug: 17695520
Change-Id: I4f2e4bb92f9178f5d095b9124a15eb2e5f13b9f6
/frameworks/base/services/core/java/com/android/server/am/BroadcastRecord.java
|
| 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/BroadcastRecord.java
|