692dcd64146786ce15c96cf054fb7808dd625667 |
|
20-Jun-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added dumsys activity starter Dumps the last state of ActivityStarter to help debug ANR issue. Also log reason for starting an activity. Bug: 38121026 Test: adb shell dumpsys activity starter Change-Id: Ib77ff974b1122946fac96f8835ab3fdfc732cf7b
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
983055231b999e450def3e3df377fb4e23420711 |
|
06-May-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #37360626: Apps can schedule alarms (and other things) with temp whitelist There is now an IBinder "token" that must be specified when setting the whitelist duration for an Intent. To have the whitelist supplied, the caller to send a PendingIntent must pass in the same token. The PendingIntent and IntentSender classes now internally maintain this token to pass in when their send() is called. The big complexity for making this work is we now need to associate this whitelist token correctly with the actual PendingIntent objects that applications and other code is getting. To do this, we propagate the token in the Notification object, and have a new API on Parcel that allows us to make it available to PendingIntent when it is unmarshalled. And this allows to deal with PendingIntents appearing in nested bundles, as we can propagate that information from the original Parcel to the new Parcel that Bundle keeps to delay unmarshalling. Test: manual Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
83c994fd85c4ad5a223e82d6ea0050dc00e28f1b |
|
01-May-2017 |
Amith Yamasani <yamasani@google.com> |
Clear calling uid before changing whitelist Avoids security exception for UPDATE_DEVICE_STATS Bug: 37627773 Test: manual Change-Id: I18617d068e7db0813c11b23b281d283908664eae
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.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/PendingIntentRecord.java
|
f66adfd1cd0dd565d7ba497da28a407e69995272 |
|
13-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Add new facility to find out when a PendingIntent is canceled. This is just an internal API in the platform, not (yet?) available in the SDK. But it will be useful for system services that want to clean up state if a pending intent that has been registered with them is canceled (either explicitly by the app, through the app being uninstalled, etc). Also improve the activity manager's dump of pending intents to organize them by package, making it much easier to read (now that we have so many active pending intents these days). Test: ran and booted. no CTS, since no API. Change-Id: Iad029cfedcd77e87357eca7da1b6ae94451dd981
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
08992ac57e973d6bf32693725ebb341a481e5944 |
|
21-Mar-2017 |
Christopher Tate <ctate@google.com> |
API refactor: context.startForegroundService() Rather than require an a-priori Notification be supplied in order to start a service directly into the foreground state, we adopt a two-stage compound operation for undertaking ongoing service work even from a background execution state. Context#startForegroundService() is not subject to background restrictions, with the requirement that the service formally enter the foreground state via startForeground() within 5 seconds. If the service does not do so, it is stopped by the OS and the app is blamed with a service ANR. We also introduce a new flavor of PendingIntent that starts a service into this two-stage "promises to call startForeground()" sequence, so that deferred and second-party launches can take advantage of it. Bug 36130212 Test: CTS Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345 (cherry picked from commit 79047c62b58fb0a0ddf28e2b90fe4d17e05bc528)
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
02b7a83b97593bc0c0c459272dca15d2e7ef8dd5 |
|
07-Oct-2016 |
Andrii Kulian <akulian@google.com> |
Make stack field private in TaskRecord This is needed to enforce usage of setter - prerequisite for ag/1499587. Change-Id: I194008899d8320a213e82b9106f0589f499941b4 Test: Refactoring only. Manual and existing tests still pass.
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
f24d606a45ce9953911fa6fafcc7eb76dcafbfa9 |
|
20-Jul-2016 |
Rubin Xu <rubinxu@google.com> |
Handle null packageName in PendingIntentRecord Bug: 27896795 Change-Id: If187e4c9cf4e5a0461f207fd8c8576bcfa559999
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.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/PendingIntentRecord.java
|
a1b79bfd7a15006a93da933695359765e0fee495 |
|
24-May-2016 |
Felipe Leme <felipeal@google.com> |
Allow apps to bypass Power Save restrictions when launched from a Notification's PendingIntent. This scenario typically happens when the device is on Doze Mode and a notification action is triggered from a Wear device. In a nutshell, the workflow is: - ProcessRecord has a flag telling whether a process has "whitelist management" privileges. - When NotificationManager binds a new NotificationListenerService, it sets the BIND_ALLOW_WHITELIST_MANAGEMENT flag. - On bind(), ActiveService asserts that only system apps can set that flag. - On computeOomAdjLocked(), ActivityManagerService sets the ProcessRecord flag if necessary. - Upon creating a notification, NotificationManager calls AM to mark its PendingIntents as coming from a notification. - When PendingIntentRecord sends it to the target, it checks if it's from a notification and if so calls AM to do the temp whitelist. - On unbind(), ActiveService removes the ProcessRecord flag if necessary. Fixes: 28818704 Change-Id: I00d46036a2cbb73f7f733fd35bf0b743a02807a1
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
0c4e6a8da3405f742e5cef8afdf579d58b6f1246 |
|
14-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #27532364: Security Vulnerability in IIntentSender.send We need to make IIntentSender oneway... but when the system is calling that for itself, it needs to be able to return a result code. Solution: instead of directly calling the interface, we have a new IPC through the activity manager. If the thing being used is the activity manager impl, it can do the synchronous send and return the result directly in place. If not, you only get asynchronous sending and thus never a failure result back (too bad for you!). Change-Id: I4096e5b00063e8dba66230585a2dfe67e35e8092
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
f0ec2e005083808bf68f9f0049b801276c290ae2 |
|
21-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Mark even more Bundles as defusable. Bug: 27766193 Change-Id: Ib027ac7b40c7a575a76f289faabde9655338865e
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
f63b89c0a10b4e3220b0a4aa1703be3aed0c5a98 |
|
28-Oct-2015 |
Fyodor Kupolov <fkupolov@google.com> |
UserController refactoring Addressed comments from the previous cl. Added getters for UserController fields, direct access is no longer allowed. Moved the following methods: - getUserManagerLocked. Became getUserManager() - because locking is not necessary, double checked locking will suffice. - startUserInForeground /showUserSwitchDialog/sendUserSwitchBroadcastsLocked - handleIncomingUser/unsafeConvertIncomingUserLocked/isUserRunningLocked/ getUsers/getProfileIds Bug: 24745840 Change-Id: Id5a5cfb9604e08add29bd9a03c8fe5200bc51fef
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
610acda80a02317080ebaed79b0c1ce26835b8f9 |
|
20-Oct-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Introduced UserController for multi-user functionality The new helper class encapsulates user life-cycle management, provided by ActivityManagerService. Bug: 24745840 Change-Id: I8ebfa38febc4090390d1c45a9fc47398e52693ae
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.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/PendingIntentRecord.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/PendingIntentRecord.java
|
b0a78390ed834724e9c6adf0feff9931d7f9ec10 |
|
11-Apr-2015 |
Svetoslav <svetoslavganov@google.com> |
Add a mechanism to make pending intents immutable. bug:19618745 Change-Id: Ice742e0162cb9b7c0afbc32e0eea03d501666e2b
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
5f2bb4c9bc27aee581bf888f1fd22c5c9311240d |
|
13-Mar-2015 |
Craig Mautner <cmautner@google.com> |
Fix bad nesting count when remote calls fail. The nesting count for services depends on callbacks decrementing ServiceRecord.executeNesting in response to remote service calls. If a remote call fails the callback does not get made and the nesting count gets out of sync. This causes orphans in the executingServices set. This fix makes the callback locally when the remote call fails. TransactionTooLargeExceptions caused by Intents containing large amounts of data were being caught and not propagated to the calling methods. This fix propagates TransactionTooLargeExceptions back to the calling methods. Fixes bug 19698308. Change-Id: I9eb6ae414d14d6b3a2709abb1f2bdfbd4cbc3c03
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
7d701174f423754a2dade39fd16f102c085bd865 |
|
11-Mar-2015 |
Wale Ogunwale <ogunwale@google.com> |
Protect against NPE for ActivityRecords without a stack. A previous change allowed us to remove stack that no longer contained any task. This was causing some NPE when an ActivityRecord.Token or some other cached ActivityRecord later gets converted back to an ActivityRecord and we try to access its stack. Bug: 19552874 Change-Id: Ie9454bbce56591b337f97af40f8c00b8597becdf
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
e23149f1555303940d212b742707518b7f9f84ab |
|
07-Mar-2015 |
Wale Ogunwale <ogunwale@google.com> |
Converted some AMS log points to use ActivityManagerDebugConfig. Change-Id: I0563bafd29ae0bbe596ed8c06fcc573b5ead50b7
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
b916836e8dcd4aa3564479be508d7a9d73dcbce8 |
|
27-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Change ActivityView startActivity state sequence Problems arise if an activity is started in an ActivityView when the parent activity is not resumed. In particular the ActivityView can be brought to the front in front of other activities that have been started by the parent. This change checks the state of the parent when the ActivityView is starting and if it is not resumed, throws an Exception. This change also removes the queueing up of Intents if the surface does not exist when startActivity is called. Now, the owner of the ActivityView is notified when the surface becomes available. If startActivity is called before that notification an Exception will be thrown. Fixes bug 19147472. Change-Id: I6712cf1929fe65c4238ce7f3feb4e8511ed97244
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
83b6ef01a07d2e7f06dfee7fd698b27bd62ca9a0 |
|
08-Nov-2014 |
Amith Yamasani <yamasani@google.com> |
Inform PendingIntent sender if broadcast was not queued. If the broadcast could not be queued due to a stopped user, the party trying to send a PendingIntent should be notified right away. Otherwise, for instance, AlarmManager could be waiting forever to be called back after the broadcast is delivered. This is a potential fix for: Bug: 18290018 Change-Id: I07c0751e80f11e69dfa2be5c96a033aecb298b81
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
89ad456ea49cb62615ebdcac83a2515743bbe5fa |
|
25-Aug-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #16311398: Limit number of documents a process can open In application processes, monitor for when we start getting close to the Dalvik heap limit, and ask the activity manager to try to prune old activity instances in that case. Add an explicit API for apps to ask that they have their own activity instances cleaned up, if they want. Fix some bugs in launching activities that were not correctly applying the "multi task" behavior in the appropriate situations of document-centric recents. Clean up the activity manager's process removal code to all share a common path. Add a new "Spam" option to ActivityTests, which continually creates new tasks, checking that the activity manager will now prune old tasks rather than letting the app run out of RAM. And while I was was doing this, I found problems with the path for bringing an empty task to the foreground -- it could make a new task instead of re-starting the root activity in the existing task. This is fixed, and some code in the recents UI for working around the bug is removed. And as long as I am doing that, we now have nice hooks in to the activity manager for AppTask to give some APIs for better managing the task, so add those along with more tests for these APIs in ActivityTests. We should look at also having the activity manager try to prune old tasks when it sees app processes being killed, to better balance memory use across multiple processes when some processes may host many documents. That however is for another CL... Change-Id: I2bb81c3f92819350c868c7a7470b35817eb9bea9
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
a1f1a3c573acd91024fda0ceb3b921c73b186963 |
|
25-Feb-2014 |
Dianne Hackborn <hackbod@google.com> |
More battery stats. - Add events for sync. - Add more descriptive tags for wake events. - Fix battery reset. - Fix tracking of wifi data. Change-Id: Ic07f2a86a5ed33e7da57eb1108c31c777ecd801f
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.java
|
df88d73092c62a1a3cd2b2056ca63ae2e70cc238 |
|
27-Jan-2014 |
Craig Mautner <cmautner@google.com> |
Add IIntentSender to ActivityContainer.startActivity PendingIntents and IntentSenders can now be launched. Still does not work once the host activity has been paused and resumed. Window manager TaskStacks now exist independently of Displays and app windows persist after Displays are removed below them. Attaching the stack to a new Display does not yet restore the windows to it. Fixes bug 12747909. Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
/frameworks/base/services/core/java/com/android/server/am/PendingIntentRecord.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/PendingIntentRecord.java
|