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