| a6b2c883d09105b96294bbd3cab8e82be44cca2d |
|
01-Sep-2017 |
Christopher Tate <ctate@google.com> |
Properly clean up broadcast-receiver ANR
Specifically, if the only receiver component was disabled while the
broadcast was in flight *and* the app ANRed, we were failing to properly
abandon the broadcast and wound up stuck waiting for delivery completion
that would never happen.
Bug: 64854337
Test: manual
Change-Id: I9181830eca17981bf1ca403ac36f88c84c548360
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 899f54da720011d02c802958c232e1baa2941378 |
|
28-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK am: adb8c522a8
am: 436b901dbb
Change-Id: Ibe7cecd60242f1895434d586af30c2081d451f0b
|
| 436b901dbb67d580468d0f78a95faffa40d74f64 |
|
28-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK
am: adb8c522a8
Change-Id: Ia30269ec2097d5978ae3e0b3930a38b3f4441ea4
|
| adb8c522a84b5c7531b009b7a8d4c854ca7dee08 |
|
28-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reported
for normal and dangerous permissions
Change-Id: I87b10a7695d8ecfa7156525d6f3d101fc0639513
bug:62755026
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 7a8044dc6717c11c0db3fe12a6d91eedbd62a567 |
|
28-Jul-2017 |
Bart Sears <bsears@google.com> |
Revert "Report permission flags for all protections based on SDK" am: 784b56e1e6
am: 076d6f7669
Change-Id: I6034405a465919b5e4fc75b4eb109b6ae5259fe0
|
| 076d6f76698b90903496c8da55cc7bfc72fd72c3 |
|
28-Jul-2017 |
Bart Sears <bsears@google.com> |
Revert "Report permission flags for all protections based on SDK"
am: 784b56e1e6
Change-Id: Ice7dde53c5613f48d013424a7e99203fd854e532
|
| 784b56e1e64049d3bf81b7d8fa8c1ae3408c5886 |
|
28-Jul-2017 |
Bart Sears <bsears@google.com> |
Revert "Report permission flags for all protections based on SDK"
This reverts commit 852cf98cb8a4b9b56da84a96708c087996e119d2.
Change-Id: I62763bf85ec95a02a245c6b503aa34bb0e9d997a
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 2dfbbb3aa460fd01719eec1b42219e0715f02e2e |
|
28-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK am: 852cf98cb8
am: 3cf283558a
Change-Id: Iba5b20a777e4cf8953b73e523f25175d7b274a34
|
| 3cf283558a4f05cca01af4bb8de71b411995146e |
|
28-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK
am: 852cf98cb8
Change-Id: I6e87c8f40fa466f2a50f41549be41ea4fb598824
|
| 852cf98cb8a4b9b56da84a96708c087996e119d2 |
|
27-Jul-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Report permission flags for all protections based on SDK
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reproted
for normal and dangerous permissions
bug:62755026
Change-Id: I72547b0146e6b6919803e33ff64b7208c4a255ad
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 97f82f28da5a2d3bc6229fee9ce493dc037727b9 |
|
01-Jun-2017 |
Makoto Onuki <omakoto@google.com> |
Don't keep parceled extras for history broadcasts.
On dumpsys we do show history broadcast intents with extras, but
if an intent's extras are still parceled, we can't show anything
(but the length) anyway, so let's just remove them, because sometimes
they contain heavy objects such as bitmaps.
Bug: 62144301
Test: manual tests: Boot, add account start apps, insert SIM
Change-Id: Ia64dd46d66fba3098e32c435509f4940ae978710
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 54c10dca588745aad9ba069e1cd70fd702b7faeb |
|
19-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Merge "Maybe fix issue #62199092: Alarm didn't ring, upcoming alarm..." into oc-dev
am: 8a95d49d8f
Change-Id: I2d59709712d96b78e1bd5d634e6c31cc0a0d6ff0
|
| 443d35a0013ef878568045bdd26e996718137944 |
|
17-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #62199092: Alarm didn't ring, upcoming alarm...
...notification was stuck
Don't deliver to a ProcessRecord that has been killed, instead
go through creating a new process.
Test: manual
Change-Id: I74eb0843200b5b99d6496e4b3f6eef5ed38c926e
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| d1294465fbbf05b831d4e5d718bae229314635de |
|
06-May-2017 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Offer to wait until broadcasts have drained." into oc-dev am: 6f4aab2c01
am: 8c921a8f14
Change-Id: Ia55b3b9666b2683e880e07071b53645ba309a57c
|
| 6f4aab2c01280fc563fb1535621c0d0d7cb34221 |
|
06-May-2017 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Offer to wait until broadcasts have drained." into oc-dev
|
| fd65813157e4dd7fa9f0b7c5dd4c8f536cc6316a |
|
03-May-2017 |
Jeff Sharkey <jsharkey@android.com> |
Offer to wait until broadcasts have drained.
We've seen evidence of lab devices racing with other apps that are
using cache space immediately after tests wipe it clean, which can
cause test failures. To mitigate this, try our best to wait for the
device to go "idle" by watching for broadcast queues to fully drain.
Also improve javadocs along the way.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37486230, 37566983, 37913442, 37914374
Change-Id: I4d430db443b6fa6d33a625fe07b90279b5d51c12
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 617a922a8969032fe49df73285799c3595a3f84a |
|
05-May-2017 |
Amith Yamasani <yamasani@google.com> |
Merge "Update process state after unbinding a service." into oc-dev am: f57b93cd0a
am: dccddf02a9
Change-Id: I8f4082ac526cdfa6f206ffcdbbc498c38bbfff48
|
| 385c3ad9955d729ac691f221e82131c349a42b74 |
|
04-May-2017 |
Amith Yamasani <yamasani@google.com> |
Update process state after unbinding a service.
Bug: 37334267
Test: manual
Change-Id: I5304ea26a1e742523b7b22fa0c7e1ab7d1ece9b3
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 68783347d5e9d0b3651ddf83c78d22cb3e4fcae1 |
|
26-Apr-2017 |
Narayan Kamath <narayan@google.com> |
ActivityManager: Remove vestigial support for mDidDexOpt.
Code is currently dead, mDidDexOpt is never set to true
anywhere.
Test: make
Bug: 37701348
Change-Id: I8b2536f5df0f60ea4d609b7e6eeba13c2368c2b5
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| c05f5d12d9a1b98221833ec0919d081a869d2486 |
|
25-Apr-2017 |
Todd Kennedy <toddke@google.com> |
Add concept of implicitly exposed components
Implicitly exposed components are those that can still be accessed
via generic startActivity() calls. However, they cannot be started
by specifying a package or component. Additionally, package info
can't be obtained if the package only has implicitly shared
components.
Change-Id: I404a4dff87559cfeee6ad78f7dcc7f5d849d6869
Fixes: b_37343345
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| e4d1a2e0daf8a3a6fa6b0f327523ebc381386cde |
|
15-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #36858643: Runtime restart on OPR1.170323.002
We had a layering problem between alarm manager, device idle
controller, and activity manager. The layering should be, from
bottom to top:
activity manager
alarm manager
device idle controller.
However in the path of activity manager's PendingIntent.send(),
it would do a direct call to device idle controller. It was
careful to do this without its lock held, but that isn't enough.
In this case, alarm manager is doing send() with its lock held,
expecting that to be safe, but it ends up causing it to call up
in to device idle controller via the activity manager (in order
to update the temporary whitelist).
To fix this, activity manager now has an internal data structure
representing pending temp whitelist requests, and all it does is
add to that during the call in, scheduling a message to later
dispatch those to device idle controller. But to make things
correct, we need to use this data stucture to act like the uid
is already on the temp whitelist even before we actually dispatch
that message. (So we don't have races with things calling
startService() for example.) So all the existing stuff looking
at the temp whitelist that is handed down by device idle controller
will also consult with this data structure of pending changes.
Test: bit CtsAppTestCases:ActivityManagerProcessStateTest
Change-Id: Id444b7ad3e694dc977c7f4fa236fbad855ce4066
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| b8633f3a2e7b408de7dbd0411f188c66cc8fd726 |
|
12-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #37220301: Allow broadcasts with permissions to not be restricted
Allowed!
Test: new CTS tests added.
Change-Id: I16f49746c0d6f5368625b54df6ffb510aa4cb5ab
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| abd2b66e96345ec92b09fe07d3f5963c16f821b8 |
|
16-Mar-2017 |
Chad Brubaker <cbrubaker@google.com> |
Dont send broadcasts to manifest-receivers in IA
Instant Apps should only be started via user interaction and only
support having runtime receivers.
Test: Broadcast not sent to an Instant App
Change-Id: Ic2cfb33e8ca6a99045ad1cfd6c79f7d3e8d41001
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 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/BroadcastQueue.java
|
| b7e34d5508b41c421994eb70f96f56e5db7ede74 |
|
22-Feb-2017 |
Chad Brubaker <cbrubaker@google.com> |
Only send exposed broadcasts to Instant Apps
In order to prevent Instant Apps from receiving potentially sensitive
broadcasts they will only receive those that the sender explicitly
exposes to Instant Apps by setting
Intent.FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS.
Bug:33350280
Test: `adb shell am broadcast` does not get delivered to Instant App
Test: `adb shell am broadcast -f 0x0x200000` gets delivered to Instant
App
Test: Verified that an Instant App can send a broadcast to itself
without FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS
Change-Id: Ie363448bf224abba530dd4caf69258939fff00af
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 1ec752f2dac36b2bf32a9d3fdf5f1f022a09228c |
|
03-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add tracking of bg check violations in broadcast stats."
|
| 3e7d845161870f6289aeecdf4bfd762097f487d6 |
|
03-Mar-2017 |
Makoto Onuki <omakoto@google.com> |
Make sure to call the original reply-to receiver when...
replacing a queued broadcast.
- Also don't replace a broadcast for a different user.
Test: Manual test with the following test code:
Intent intent = new Intent(Intent.ACTION_PROVIDER_CHANGED)
.addFlags(Intent.FLAG_RECEIVER_REPLACE_PENDING);
AlarmManager alm = this.getSystemService(AlarmManager.class);
long time = SystemClock.elapsedRealtime() + 5 * 1000;
for (int i = 0; i < 5; i++) {
alm.setExact(AlarmManager.ELAPSED_REALTIME, time,
PendingIntent.getBroadcast(this, i, intent, PendingIntent.FLAG_UPDATE_CURRENT));
}
Without this CL, after the alarm fires, AlarmManagerService.mBroadcastRefCount
is left > 0 and the wake lock is held forever.
With this CL, mBroadcastRefCount eventually gets back to 0.
Bug: 35779096
Change-Id: I4e21c94b08f25f9ca1242182670ff4a69f8bd9f2
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 7fc46d8bcca52b623a42639853379db59b3f065b |
|
15-Feb-2017 |
Dianne Hackborn <hackbod@google.com> |
Add tracking of bg check violations in broadcast stats.
Test: manually booted and checked output
Change-Id: Ie29a8424ae80c2b193645dcb2b1f4f6a8779ff6a
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| a68e3450ffa7a0905a30d9cab4ec869e4006257f |
|
17-Jan-2017 |
Carmen Jackson <carmenjackson@google.com> |
Add tracing for broadcast sending and processing.
This change instruments BroadcastQueue using asyncTrace to give us
visibility into broadcasts from a trace. There's one traced section for
the time the broadcasts spend in the queue, and another one for the time
it takes to dispatch the broadcast.
My previous solution for this bug was incomplete, so this change also
cleans up that solution (which instrumented a callsite). Last, there's a
couple minor changes to logs (fixing a typo and making a log clearer).
Bug: 33645477
Test: https://screenshot.googleplex.com/2F6SWiCtEUD
Change-Id: I27e38cd70fee144986405bae302eb04045dff06d
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| c3af19a87dc70c321ffcc1e90453bb6f0545aef2 |
|
21-Jan-2017 |
Dianne Hackborn <hackbod@google.com> |
Optimize bg check flow.
No longer need to look up the application info, target SDK is
explicitly passed in to the check. For the external method, we
change this to just checked to see if background is completely
disabled, which doesn't need a target SDK check (and is the only
thing any of the current clients care about).
Now allow SystemUI to put targets of notification pending intents
on the temporary whitelist when they fire, so developers can avoid
dealing with background restrictions in this case (if the user
interacts with their notification, they will temporarily be
considered in the foreground).
Remove any thoughts of enforing restrictions on registerReceiver(),
so we don't need to deal with target SDK versions there (which can't
be done all that efficiently).
Also bring back the old "allow starts coming from foreground apps"
only for the MODE_IGNORE app op, since it should provide some
better compatibility.
Test: ran them.
Change-Id: Id4ea7f992d12ce4bd8e54f1dbaeb4a460a3dee59
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 42a386b7717300bf6d75cbd3b4f7ad00f294be0d |
|
07-Nov-2016 |
Christopher Tate <ctate@google.com> |
Enable background restrictions
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 9e83cbbc10014b3ed560b3181f594868cd89f9ae |
|
19-Jan-2017 |
Chris Tate <ctate@android.com> |
Revert "Enable background restrictions"
This reverts commit 21f778060badb1e78bffde05e8de7662d275003d.
Change-Id: I65586f9739da84fb32b51b0ea166b8288c41d1b3
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 21f778060badb1e78bffde05e8de7662d275003d |
|
07-Nov-2016 |
Christopher Tate <ctate@google.com> |
Enable background restrictions
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| e07641d4fbdd0528c18305213e861a6e1aff4a3b |
|
10-Nov-2016 |
Dianne Hackborn <hackbod@google.com> |
Start implementing background restrictions for eph apps.
This implements the additional intended path for checking
allowed background operations, APP_START_MODE_DISABLED, which
doesn't allow an app to launch in the background at all.
Also change the semantics of delivering broadcasts to manifest
receivers to always restrict those, not changing based on
whether the app is currently idle. This is the desired intended
behavior for apps as they explicitly update to work with
bg check.
And now that we have ephemerality associated with the uid state
in the activity manager, we can propagate this through the
relevant callbacks in IUidObserver so things watching these
changes can immediately determine whether they should do their
more aggressive shut down work for the uid rather than having
to walk through all their state looking for package associated
with that uid and whether they should be shut down.
Also remove the "lenient" bg check mode, since that was
just an early experiment that we won't actually use.
Add a new "make-idle" activity manager command to immediately
put a uid into the idle state (if possible) to make it easier
to test.
Test: manually against an eph app
Change-Id: I43a138ff281f69a9251d3f29ab6e13f48cff8ad6
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 22f3aa3b487308ccd86195491476b4cdff853d4e |
|
17-Oct-2016 |
yangzhenyu <yangzhenyu@xiaomi.com> |
Merge "[ActivityManager] Fix the inconsistence between ProcessRecord and BroadcastQueues" am: 09dcaf1948 am: 744f0e0997
am: 6bdc11f95f
Change-Id: I18a747cffe5d81e10bbc5d63b95a36521883e933
|
| 744f0e0997f08f00786e4f0266d8cbdb4b2b4569 |
|
17-Oct-2016 |
yangzhenyu <yangzhenyu@xiaomi.com> |
Merge "[ActivityManager] Fix the inconsistence between ProcessRecord and BroadcastQueues"
am: 09dcaf1948
Change-Id: I6227536c270cdac730be60edf35f7ff704e59af0
|
| d509bc93e6d13d46c45707d76ae95a6f735fc037 |
|
31-Aug-2016 |
yangzhenyu <yangzhenyu@xiaomi.com> |
[ActivityManager] Fix the inconsistence between ProcessRecord and BroadcastQueues
Symptom:
Even though one process is executing one BroadcastReceiver,
it may be killed as one EMPTY process occasionally
Detail and sample:
https://code.google.com/p/android/issues/detail?id=221524
Root cause:
app.curReceiver can only remember the last running.
If an application is both receiving FG and BG broadcast,
when one is finished, app.curReceiver becomes null,
the state of application becomes EMPTY.
Solution:
save all running receivers at ProcessRecord
Change-Id: I01b8813af652a8c434be7de0678dc06f99831ae0
Signed-off-by: yangzhenyu <yangzhenyu@xiaomi.com>
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| a1c0bdbde0cc4ea55780a2730824f5dfa4c54ca5 |
|
06-Oct-2016 |
Nimrod Gileadi <nimrod@google.com> |
resolve merge conflicts of 448489a to cw-f-dev am: f2122f5f96
am: da2908cf67
Change-Id: Ia169a8a4db36229638997d5a09b86fe964d0c533
|
| f2122f5f960bb4aa69fdd11c859eeada99de3e1c |
|
06-Oct-2016 |
Nimrod Gileadi <nimrod@google.com> |
resolve merge conflicts of 448489a to cw-f-dev
Change-Id: Idaff9ccaf74bf0ec82c6346eb383295b508c7324
|
| 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/BroadcastQueue.java
|
| bd912314c308f305baf4ce02fbb215942cc74283 |
|
18-Aug-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Work on issue #29939676: android.util.ArraySet static cache corruption"
|
| ad51be90d8dbac8eb9a36ce07c423d24e4b0b321 |
|
17-Aug-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #29939676: android.util.ArraySet static cache corruption
Clean up method names to be consistent with locking protocol...
hasn't uncovered a locking problem yet, though.
Also remove some dead code.
Change-Id: Icdfd320a420b2beb47c805c32ac04db4b61e6a8c
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 77df6f315d6fbb22622ca46ae5735a5c73cc367d |
|
17-Aug-2016 |
Svet Ganov <svetoslavganov@google.com> |
Remove permission review build property - framework
Change-Id: Ifcfd436f2d57a6006ef804292d2875434e4669da
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| f4825a431d3f4ab9a8e0b3b7a3a7392724405f8b |
|
12-Aug-2016 |
Amith Yamasani <yamasani@google.com> |
Clean up when recycling a pid with a pending launch am: d86e14e45c am: 92de60bd7f
am: 1fa3fd30bd
Change-Id: Ib4e36dc0be9c6a73907bbdf7f146a20e0d2eeb3f
|
| 92de60bd7fce725404ee2ace951b68aed4f0bf25 |
|
11-Aug-2016 |
Amith Yamasani <yamasani@google.com> |
Clean up when recycling a pid with a pending launch
am: d86e14e45c
Change-Id: If77af8cc8a0b9620c2fc5e4704c178667fc0703e
|
| d86e14e45c15cd1a17925d9cb131471d496ab389 |
|
06-Aug-2016 |
Amith Yamasani <yamasani@google.com> |
Clean up when recycling a pid with a pending launch
Fix for accidental launch of a broadcast receiver in an
incorrect app instance.
Bug: 30202481
Change-Id: I8ec8f19c633f3aec8da084dab5fd5b312443336f
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 5ca0bcd66a6cdcbac154a3d5e24a16bd740348b4 |
|
03-Aug-2016 |
Erik Wolsheimer <ewol@google.com> |
Store parameter object's intent field to local var am: 5d34f00e32
am: 97b9d8f0a4
Change-Id: I935cc5b5425ced40bf9f3fe0a82fadc2f2f1209e
|
| 5d34f00e329398005022091b9437d4bc14376fd2 |
|
28-Jul-2016 |
Erik Wolsheimer <ewol@google.com> |
Store parameter object's intent field to local var
BUG: 30180571
Change-Id: I5a96b41a0c036e5e0a3ab097ff88e1caf6b3b0cd
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| ac69be543f89ea6e9a27204492e0a170d9b3450e |
|
30-Jun-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Add Bluetooth toggle prompts - framework
If permission review is enabled toggling bluetoth on or off
results in a user prompt to collect consent. This applies
only to legacy apps, i.e. ones that don't support runtime
permissions as they target SDK 22.
Also added a configuration resource which controls whether
permission review mode is enabled. By default it is not and
an OEM can change this via an overlay. For now we also keep
the old mechanism to toggle review mode via a build property
which is still used and will be removed when clients have
transitioned.
bug:28715749
Change-Id: I94c5828ad6c8aa6b363622a26ff9da4fc2e2fac7
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| ea05cd57f5b2b26650276a7ff03053e7cb78c538 |
|
20-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29438842: Enter the "am broadcast -a...
...'android.hardware.action.NEW_PICTURE'" to terminal, but does not have a response.
Change-Id: I264f386810237a7abc767f68363afeccda557b9c
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| b5f3b5c2e5108b875fdb21726eeca41f58d59d49 |
|
16-May-2016 |
Amith Yamasani <yamasani@google.com> |
Don't deliver broadcast to apps that are being backed up
When doing a full backup, mark the process as being in
backup and don't deliver any broadcasts to an app in
that state.
Bug: 25350780
Change-Id: I1adc95431f709495d3c1141c7c5d3616cf9cc1f0
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 2675616719734ce069db47bd8b563f775351dd38 |
|
17-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #28689719: Runtime restart
There are few paths I can see to get a null intent down into
the framework at this point. Add in some checks and reports
at those places to mitigate and report such problems.
Change-Id: If235bf342558321d3fabe9363fcebb2bcea18df1
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| ca82e616d3131570bf2ee29778f4796f343720d5 |
|
20-Apr-2016 |
Brian Carlstrom <bdc@google.com> |
Add reasons to notifyPackageUse calls
This is so we can record more specific times in PackageUsage.
If file with only one timestamp per package is found, the value is
copied to all usage slots.
Bug: 27902702
Change-Id: I8affe43c735e54620a9204433aad367cfddfded7
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 5869d1c5b67b8e8ee22696318ffb31316dcbb089 |
|
21-Apr-2016 |
Joe Onorato <joeo@google.com> |
If we can't call into an app process to deliver an intent, crash the process.
Rather than hoping the process will crash for some other reason, it is
better to just get rid of it right away. The Intent was not delivered,
so there are no guarantees that the app will continue to function
correctly.
Bug: 28196243
Change-Id: I036fbc5ffd42dc7259437cc5a733976478a2dd3a
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| e91f3e7e8d8aec8b880e6ed284a3889f849dfd91 |
|
26-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #27776639: Background Check: Conn_Change...
...shouldnt be received when app is awake
(Really any implicit broadcast.)
Fix up a few things so we are more strict when not in lenient
mode.
Change-Id: I3c711525787e07ea7c604d0f9bc123e02448fa68
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| a49ad09c6f772fdbf829f85a6977fcde243c2b98 |
|
03-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #27381069: Master tracking bug: NYC is Sluggish
Have the activity manager us its own scheduling priority constants,
so that the new relative comparisons it is doing will work out
correctly.
Change-Id: I7bd1e5a3178ea491117bc497f87e4b75c92e0bc8
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 20d7df3c3ff0000678a208b25fcf7ddf90c5abe4 |
|
12-Jan-2016 |
Adrian Roos <roosa@google.com> |
Crash dialog improvements, move crash code to AppErrors
Factors out the crash and ANR handling code into separate
class and allows clearing cache and restarting app from
crash dialog.
Bug: 22692162
Change-Id: I2a08a4255ea02ab3c7441d351bf278128fcf5a5d
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 0c6cc308cfd26ae102a1a3deb258e675da2c1eb0 |
|
10-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add new target SDK filtering feature to BroadcastOptions."
|
| 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/BroadcastQueue.java
|
| 76e800928f46337a1b365b21bf752a44ffd1954d |
|
09-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #26102692: Unable to create secondary user...
...device restarts while adding account or password in SUW
Change-Id: Ibcacb034720133359509b1be1b289abe68be44b4
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| 2639c4bf6b98fb60a47f7398966d184a0aea1950 |
|
04-Dec-2015 |
Dianne Hackborn <hackbod@google.com> |
New generic background restrictions.
This modifies the existing rigid background restriction to
a more moderate policy that we can (eventually) apply to all
apps:
- After N minutes no longer in the foreground, any background
services running in the app are stopped and no more can be
started.
- No manifest receivers for the application will be executed
if the broadcast is not being sent explicitly to that app and
the app is not running. (Eventually we should tighten this so
they won't be received if the app is past its N minute
background window.)
- Other non-background processes may still bind to services in
the background process, which will raise it to back to an
executing state... so things like syncs, jobs, live wallpapers,
accessibility services, etc still work.
Change-Id: I08ddbfdf640ef324a27b2eb9eecd9499f3ebddd9
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 9c165d76010d9f79f5cd71978742a335b6b8d1b4 |
|
02-Dec-2015 |
Svet Ganov <svetoslavganov@google.com> |
Add optional permission review for legacy apps - framework
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| bef28feba57be7fd6a4d14a85a8229154338b2ed |
|
30-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial stab at background check.
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 27c073796978106746e4a51f2100b29068ab37f6 |
|
05-Nov-2015 |
Nicolas Geoffray <ngeoffray@google.com> |
Remove performBootDexOpt and am's ensurePackageDexOpt.
Except common shared libraries and boot image, all compilations
are now done through BackgroundDexOptService.
Change-Id: Ib736e253c38b0c8085bc94e45f4e61a048f66e26
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| fb9ec50795142c24b56dd28e45f5012b9b445380 |
|
01-Sep-2015 |
Svetoslav <svetoslavganov@google.com> |
Incorrect app op check in broadcast queue
An intent broadcaster can specify which permissions should be
held by a receiver to get the broadcast. These permissions may
have corresponding app ops and if this is the case we also
check the app ops. There is a bug in broadcast queue where if
a permission does not have an app op we still try to check this
app op and get an exception as the app op does not exist. This
did not manifest often because the broadcast API takes an
optional app op against which is compared the app op for each
permission and if they differ the app op for the permission is
checked.
bug:23725305
Change-Id: Iec56ee354bbc11e7bc245134cf3afd2c11eecbc4
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 24b243d53d47ba132588aadf5336f2394c6193fe |
|
17-Jul-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed bad merge conflict resolution
https://android-review.googlesource.com/#/c/137534/ was accepted
and merged on 03/04/15. However, a bad merge conflict resolution
caused half of the change to be reverted. This adds back the missing
change.
Change-Id: I4f7c2503e60321b692e12316961958b149baf4ea
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| fd854ee58c5d56f84047007ead9f88a767ae956f |
|
14-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21626564: MMS should be receivied while Dozing
We now place whoever is receiving the MMS on the temporary
whitelist while doing so, so they can get network access to
download it.
There was also an issue that needed to be fixed where we
were no longer updating the list of allowed uids while
dozing based on their proc states... we now do that.
Also did a bit of optimization of the temp white list update
path do the network policy manager, instead of going through
a broadcast we now directly call in to the network policy
manager. This also allows us to have a synchronous version
of updating the list, so we can know the app has network access
before we tell it to do anything.
Finally added battery stats events for things going on and off
the whitelist so we can diagnose the behavior there.
Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.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/BroadcastQueue.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/BroadcastQueue.java
|
| 99b6043dad9d215cf15810b885b6b8c215dd5b5a |
|
27-Jun-2015 |
Svet Ganov <svetoslavganov@google.com> |
Teach receivers, activities, providers, and services app ops.
Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.
bug:22199666
Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| a22c6328309d3c9e8bf7209bff87d104fbcb60ba |
|
03-Jun-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed outOfBoundsException when logging discarded receiver.
Bug: 21607321
Change-Id: I6f7ee4581ae2f0a0b7caedb84190fadc0edccfe8
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| 540e123b14ef71f0bfda325e11773c1c510fb8ba |
|
02-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Clean-up component states in AMS when component is disabled
Bug: 15804187
Change-Id: I2b5856c5a0a012f34698fb64f8596d32924bbd1f
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| c14624da8e6155fccbe3c0e9a3623ed5385224ff |
|
29-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Some code clean-up.
Change-Id: I626c4c40c32dbf43408e0649364dfe8be2bb2321
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| f278f12fae6b0dada39fbdf90a84406053937933 |
|
22-Apr-2015 |
Christopher Tate <ctate@google.com> |
Retain milestone timestamps of historical broadcast activity
Also use a ring buffer now instead of using arraycopy() every time
we send a broadcast.
Bug 20297662
Bug 20426398
Change-Id: I682461f358e5bc6ebc63bbeb87d0ad07d85fe4b6
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 4f2dcfd48010a338dc9a2f5870ed12b382c30cd7 |
|
22-Apr-2015 |
Svet Ganov <svetoslavganov@google.com> |
Fix permission check imposed by broadcast sender.
Change-Id: Id105b00aad7b369fa0337fa63753ce7ea71b3383
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| bfac468ce907643eda50afa28f25538b9182e65e |
|
08-Apr-2015 |
Wale Ogunwale <ogunwale@google.com> |
Throw caught DeadObjectException when trying to create a service.
We don't want to continue trying to start the service if the service
appliction is dead. This will lead to an NPE later on since we have
set ServiceRecord.app to null in the finally block.
Bug: 5227987
Change-Id: I3ee5111f4a20d9455fedbf41ac54d41c43aa8d76
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| c6d1c345f41cf817bf2c07c97b97107d94296064 |
|
26-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Runtime permissions: per user permission tracking.
Before all permissions were granted at install time at once, so the user
was persented with an all or nothing choice. In the new runtime permissions
model all dangarous permissions (nomal are always granted and signature
one are granted if signatures match) are not granted at install time and
the app can request them as necessary at runtime.
Before, all granted permission to an app were identical for all users as
granting is performed at install time. However, the new runtime model
allows the same app running under two different users to have different
runtime permission grants. This change refactors the permissions book
keeping in the package manager to enable per user permission tracking.
The change also adds the app facing APIs for requesting runtime permissions.
Change-Id: Icbf2fc2ced15c42ca206c335996206bd1a4a4be5
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 3c36b8e9569292b7da9a916b148a21dd6c273dc9 |
|
09-Mar-2015 |
Wale Ogunwale <ogunwale@google.com> |
resolved conflicts for merge of ca54b876 to master
Change-Id: I3148551b9809fb5c36007b26f26acf812b2f654d
|
| d57969f6ec38c7633ca65bcd5bdd766cd972cfe4 |
|
16-Nov-2014 |
Wale Ogunwale <ogunwale@google.com> |
Made AM package debug log more configurable.
* Added class ActivityManagerDebugConfig.java for housing all debug
log configuration for activity manager package.
* Added ability for using default activity manager log tag or class
specified tag string which is very helpful during debugging.
* Added ability to prepend log category name to log tag that can
also be useful during debugging.
* Converted BroadcastQueue.java and ActiveService.java to use the
new log class. Other classes in the package will be gradually
converted.
Change-Id: I0e4b343da75cb2e539b5ad5f0f79f6bc7af46d7b
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 01eb7fa7f99ebc410ae0bf17ea8fec8e61e694f0 |
|
04-Mar-2015 |
riddle_hsu <riddle_hsu@htc.com> |
[ActivityManager] Skip receiver precisely.
Symptom:
Report broadcast ANR on a dead process.
Detail and sample:
http://code.google.com/p/android/issues/detail?id=158329
Root cause:
app.curReceiver can only remember the last running.
If an application is both receiving FG and BG broadcast,
only one of queue can discard, the remain one will still
count as timeout.
Solution:
Select the skip-tartget-receiver by comparing the skipping app
to the first record of mOrderedBroadcasts of each broadcast queues.
Change-Id: Ic68d56f21b417a34f2d30d64ecfbed09c5e1764d
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.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/BroadcastQueue.java
|
| d2f1511f2896e09db35bd92e0aab02ba89888a04 |
|
22-Jan-2015 |
Todd Kennedy <toddke@google.com> |
Don't get extras from the Intent
When handling Intents in the system process, we need to be careful
to not cause the extras bundle to be unparcelled. If the extra is
unparcelled, any custom class added to the extras will throw a
ClassCastException during the unparcel. For legacy reasons, we
would get the "seq" extra from the Intent for broadcast debugging.
This violates our requirement to not unparcel extras in the system
server process.
Bug: 19068243
Change-Id: I6cac426a0ef8648a05ded69ee4ac244017d9b5d1
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 4472fa97800fb20b045f1907372f75d2b37b137e |
|
17-Jul-2014 |
Kenji Sugimoto <kenji.xb.sugimoto@sonymobile.com> |
Prevent ANR when broadcast receiver is killed
If the process of a BroacastReceiver is dying at the same time
as the system is trying to send an ordered broadcast to the
receiver, the system will try to start the process again. The
BroadcastQueue will store the BroadcastRecord in mPendingBroadcast
to be able to handle it again when the process is awake. A
timeout Message is posted to the handler of the BroadcastQueue.
As part of the shutdown sequence skipCurrentReceiver is called for
the ProcessRecord. This will check if there is a curReceiver set
for the application and make sure to finish the receiver.
Each of the foreground and background BroadcastQueues have their
own handler for managing broadcast timeouts. If the wrong
BroadcastQueue finishes the receiver, the pending timeout Message
will never be cancelled, leading to an ANR report for a receiver
that has already been finished.
Change-Id: I960c0d8f1a8b739b54a8f09f496b32a3498b9e9a
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 04d0bb6e933519d2287bef1c6ce2482c0dc61493 |
|
07-Mar-2014 |
Guobin Zhang <guobin.zhang@intel.com> |
ANR caused by incorrect cleanup in BroadcastQueue.
Two broadcasts could be sent to the same app simultaneously:
one foreground, one background. For example, LOCALE_CHANGED
and PACKAGE_CHANGED are delievered to com.android.vending
at the same time.
1. AMS started new vending process to handle LOCALE_CHANGED.
And set app.curReceiver = LOCALE_CHANGED.
2. Before LOCALE_CHANGED is handled by vending process,
PACKAGE_CHANGED was delievered to vending process too.
AMS set app.curReceiver = PACKAGE_CHANGED. Bad!
3. Vending process finished handling LOCALE_CHANGED.
AMS clear app.curReceiver = NULL. Bad!
And Vending process killed itself without handling
PACKAGE_CHANGED.
4. AMS known vending process has died, but didn't know that
BgBroadcastQueue was still waiting for finish message
for PACKAGE_CHANGED.
At last, BgBroadcastQueue reported ANR for PACKAGE_CHANGED.
This patch adds protection before clearing app.curReceiver,
only set to NULL if the finishing receiver = app.curReceiver
So handleAppDied would know that PACKAGE_CHANGED was not
finished yet, it will abort the broadcast and continue.
Change-Id: Ic4f31b35e21823d4a3c27712391ecbede213a494
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 8d05172112436a81bed6e4a0810f8914509d8a4d |
|
01-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager
Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 38c1a5f5a94ea2fd0bea604a2f8c202e871d9bb2 |
|
21-Jul-2014 |
Craig Mautner <cmautner@google.com> |
am b7bb95b0: am 02fd104f: Merge "Skip broadcasting to a receiver if the receiver seems to be dead"
* commit 'b7bb95b0f3cd8b2ccb61cfa75a586fe1df1be123':
Skip broadcasting to a receiver if the receiver seems to be dead
|
| f7097a5b697fedb6976774e55a51471405a23c0e |
|
13-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Add kernel and native memory data to procstats.
We now collect memory use data in the kernel and native
application for aggregation in procstats. This should
allows us to do aggregated summaries of how memory use
is distributed across the system -- how much is free vs.
how much is in use.
Fix a bug in how we were tracking per-app version codes:
apps that used a shared user id to have multiple packages
run in the same process could get their version codes
cross-wired. Now we keep track of version codes in the
list of packages associated with a process.
Bumped the checkin version code to 5, so that we can
distinguish checkins that have this corrected data.
Also fix a bug in battery stats monitoring radio state.
Change-Id: I1c849f2df442df679a34ad7b0ca0c5870bfac8df
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 4b9d79c30eccb61645d98a4f0d49b7769e8c7ccc |
|
22-May-2014 |
Amith Yamasani <yamasani@google.com> |
Fix singleUser attribute
Make it work correctly for singleton content providers.
Relax which apps can export singleton content providers.
Change-Id: I43d315c25ed76a876bfa6d5e0d1351bc19c9bdba
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 684bf34ee8acc41931fac23762b13e14a22011db |
|
30-Apr-2014 |
Dianne Hackborn <hackbod@google.com> |
Switch IProcessObserver to report process state
When IProcessObserver was created, the only information
we had for the state of a process was its "importance".
Now we have the process state, which is much more useful.
Switch to reporting that.
Change-Id: Icdb3eea8cf96f4eff7ed3d584f940a1bd9cc3884
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 09d30981f8e882ffaa336aa4665bfe348557895a |
|
16-Jan-2014 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 6f357d32 to master
Change-Id: I1979e6ed1acddbe656f5010114fd900f10865e75
|
| 6f357d3284a833cc50a990e14b39f389b8972254 |
|
16-Jan-2014 |
Jeff Brown <jeffbrown@google.com> |
Start untangling system server early bootstrapping.
Refactored SystemServer to get rid of a bunch of legacy cruft related
to how the ServerThread used to be started up.
Create system context first when system server starts. This removes
the tangled initialization order dependency that forced us to start
the activity manager service before most anything else.
Moved factory test related constants into the FactoryTest class.
Partially migrated Installer, ActivityManagerService, and
PowerManagerService to the new SystemService pattern. There's more
work to be done here, particularly around the lifecycle of the
power manager.
Bug: 12172368
Change-Id: Ia527dd56e3b3fd90f9eeb41289dbe044921230d4
/frameworks/base/services/core/java/com/android/server/am/BroadcastQueue.java
|
| 49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
| 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/BroadcastQueue.java
|