summaryrefslogtreecommitdiff
path: root/core/java/android/os/BinderProxy.java
Commit message (Collapse)AuthorAgeFilesLines
* Log wtf for warn-on-blocking on eng buildsPeter Kalauskas2023-01-191-2/+2
| | | | | | | | | | | | Log.wtf on eng builds when setWarnOnBlocking is enabled. Previously, setWarnOnBlocking would only log a WTF on userdebug builds. Bug: 32715088 Bug: 241131634 Test: Confirm eng build boots, and that calling Binder.setWarnOnBlocking(true) does not crash sysui Change-Id: Iab416c58827db558d21e518c09af1dac1569ebe8 Merged-In: Iab416c58827db558d21e518c09af1dac1569ebe8
* Merge "Support "Parcel.propagateAllowBlocking" for AIDL" am: bcefef7a8c am: ↵Treehugger Robot2022-02-021-2/+11
|\ | | | | | | | | | | | | | | 7d4245bc61 am: 4dbefbccd5 am: f1bc977e8d Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1964223 Change-Id: Ie91a206e927a8c857cc3eb556b95bae5d49e89b3
| * Support "Parcel.propagateAllowBlocking" for AIDLMakoto Onuki2022-02-011-2/+11
| | | | | | | | | | | | Bug: 216685683 Test: atest android.os.cts.ParcelTest Change-Id: I9299632c8c4fd88afc6b539270c097b9c00188b3
* | Merge "Prefer WeakReference.refersTo() to get()" am: 63e3c2c709 am: ↵Hans Boehm2022-01-271-3/+3
|\| | | | | | | | | | | | | | | aca7bb4b9f am: a2e1dc8b9a am: db7bb39fb9 Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1956816 Change-Id: I8f190ce1b3c9fc97a4efd8f3d90178db6ab362da
| * Prefer WeakReference.refersTo() to get()Hans Boehm2022-01-201-3/+3
| | | | | | | | | | | | | | | | | | | | This is an initial pass over frameworks/core to avoid WeakReference get(), since that can cause the referent to be unnecessarily retained. Most of these were found by searching for "get() == null". Bug: 215259836 Test: Treehugger Change-Id: I5227b05ca22e83b886ccf6713989961076df3f8c
| * Run a GC after killing a UID due to binder proxy limit.Martijn Coenen2021-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After we hit the per-UID proxy limit and kill the originating process, there's actually no guarantee that the proxies to the (now dead) processes are cleaned up immediately; if the processes get restarted and start accumulating proxies again, we may go over the global proxy limit (25k with this CL). Do a GC to make sure we clean them up. Note that the GC here might not actually clean up all the proxies, because the binder reference decrements will come in asynchronously; but if new processes belonging to the UID keep adding proxies, we will get another callback here, and run the GC again - this time cleaning up the old proxies. Because of this potential delay, an app may temporarily have many more outstanding proxies than the high watermark, so also increase the global proxy limit to 25k proxies. Bug: 198340142 Test: Manual Change-Id: I75c7ea4f7aa4a5d448f610014770f1b9788cfb5b Merged-In: I75c7ea4f7aa4a5d448f610014770f1b9788cfb5b
* | Add cheap aidl tracing suitable for always-on-tracing (1/3)Jorim Jaggi2021-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having only one switch to enable all binder tracing, we seperate between stack tracking and tracing. Stack tracking still works as before. However, the more lightweight option, tracing using android.os.Trace, is toggleable separately and will work on the receiver side without dumping the entire stack trace. We also make the tracing more efficient by caching getTransactionName and concatting the class name. Also, enable this selectively for SysUI+Launcher, which is currently the focus of always-on-tracing effort to figure out what kind of binder calls these processes are calling which seems to contribute a huge amount of jank (long binder calls are in >= 50% of janky traces). Test: external/perfetto/tools/record_android_trace gfx view freq sched wm am aidl Test: atest aidl_unittests Bug: 202278427 Change-Id: I4d803d073cc4b69d07fa433bfef7e1c7f45132b7
* | Increase global binder proxy limit to 25k.Martijn Coenen2021-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We know that the current per-uid proxy limit mechanism is not entirely accurate because of delayed GC; in the worst case, this means that an app can have twice the number of allowed proxies outstanding (~13k proxies). To account for this, slightly bump the limit at which we crash. Bug: 198340142 Test: N/A Change-Id: Ic6973a2dd60434b3f92041304522fcffb4fbbfd8
* | Merge "Revert sync app op chain changes" into sc-dev am: 50ff5ac8b8 am: ↵Nate Myren2021-08-031-0/+5
|\| | | | | | | | | | | | | | | 17e6177ea9 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15424412 Change-Id: I5081e4f0f78783192f553b74936a15755895e045
| * Revert sync app op chain changesNate Myren2021-08-021-0/+5
| | | | | | | | | | | | | | | | | | These changes cause some noted app ops to be swallowed due to one-way app ops. Fixes: 187721493 Test: atest AppOpsLoggingTest Change-Id: I3b761b65b2e06138fc1d130bf80587f8885bb1d5
| * Revert "binder: race condition by parcel finalize"Steven Moreland2021-05-251-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "binder: race condition by parcel finalize" Revert submission 1553275-Bug139327211_V5 Reason for revert: causing a different race condition? b/187218964 Reverted Changes: I9345f4439:binder: race condition by parcel finalize Ib06e38e22:binder: race condition by parcel finalize Bug: 187218964 Change-Id: Iebf76febdad5e231c814f1f8de454931cb9352c5 Merged-In: Iebf76febdad5e231c814f1f8de454931cb9352c5
* | Throw BinderProxyMapSizeException when hitting limits.Martijn Coenen2021-07-061-2/+12
| | | | | | | | | | | | | | To make it easier to cluster these errors. Test: N/A Change-Id: Id967c1d537ca655df2363bf38a798d632bf1b160
* | Merge "Revert "binder: race condition by parcel finalize"" am: 58787794eb ↵Steven Moreland2021-05-251-3/+2
|\ \ | |/ |/| | | | | | | | | | | am: dfda61b6c7 Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1714912 Change-Id: Ib49169804c1fa120d8fdfc9cee3531bb0baa4a34
| * Merge "Revert "binder: race condition by parcel finalize""Steven Moreland2021-05-251-3/+2
| |\
| | * Revert "binder: race condition by parcel finalize"Steven Moreland2021-05-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "binder: race condition by parcel finalize" Revert submission 1553275-Bug139327211_V5 Reason for revert: causing a different race condition? b/187218964 Reverted Changes: I9345f4439:binder: race condition by parcel finalize Ib06e38e22:binder: race condition by parcel finalize Change-Id: Iebf76febdad5e231c814f1f8de454931cb9352c5
* | | Prepare AttributionSource to expose to nativeSvet Ganov2021-05-041-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Separate the internal state of AttributionSource from the class to make it a simple AIDL we can translate automatically to native - keeping Java and native parts in sync. This would allow writing a thin native lib for checking attribution source permissions which would be used to teach camera and audio about attributions. Deinfe an AIDL interface for passing around an attribution source and opr performing permission checker oprations allowing native and Java permission checks on attribution chains to be handled. The Java side permission checker functions are in a dedicated permisison checker service on top of which sits the PermissionChecker. We expose similar PermissionChecker native APIs sitting on top of the same remote interface. The nice thing is that we have native and Java permisison checkers in sync sharing remoting code and being close in shape. For now the PermissionChecker in Java is divorced from the PermissionManager but in T we will consider how to unify them, either by an extension object on the PermmissionManager or APIs on the PermissionManager, or another approach, and then migrate clients off the PermissionChecker APIs. Sync app ops were not tracked across multiple binder calls which prevents moving the permission checks in the system server as this adds one more hop. Now sync ops are propagated backed the call stack and only the ops for the package are dispatched to it and the rest are propagated back to the caller, recursively. bug: 158792096 Test: atest CtsPermission5TestCases atest CtsAppOps2TestCases atest CtsPermissionTestCases atest CtsPermission2TestCases atest CtsPermission3TestCases atest CtsPermission4TestCases atest CtsPermission5TestCases Change-Id: Ia5cbd2eb20a2da172a5960afdddd7e467f4bcb0d
* | | Dump binder proxies interface descriptors on a separate thread.Martijn Coenen2021-04-151-17/+38
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | There are apparently some processes that block getInterfaceDescriptor() from completing, thus locking up the thread doing the binder proxy dump. This can cause the watchdog to restart system_server. Move the calls to a separate thread and give it some time to complete! Bug: 174722615 Bug: 183676249 Test: adb shell am dump binder-proxies Change-Id: Ifa79e53524197bf1d785210b7504e7f6c6ddc9b7 Merged-In: Ifa79e53524197bf1d785210b7504e7f6c6ddc9b7 (cherry picked from commit f1a22a35e85d589a4f2ba915a1997b641c81e352)
* | Merge "binder: race condition by parcel finalize"Steven Moreland2021-02-031-2/+3
|\|
| * binder: race condition by parcel finalizeJintao Zhu2021-01-281-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Root cause: 1) a client thread calls "transact", and then, reads a java binder object from the java parcel object 2) the java binder object sends BC_ACQUIRE/BC_INCREFS, but still in the queue, not yet flushed to driver 3) the java parcel object is garbage-collect-ed, and, its finalize method may possibly sends BC_FREE_BUFFER Because "BC_FREE_BUFFER" is from the java finalize thread, which is different from the "client thread", so, it is possible that "BC_FREE_BUFFER" will be flushed to driver before "BC_ACQUIRE/BC_INCREFS", which makes driver destroy the related "binder_ref" object prematurely. Consequences of the issue: The user space process might always hold the above java binder object, whose "handle value" is indeed invalid because the related "binder_ref" in driver is destroyed. This causes a lot of chaos inside the process: <a> any binder call on the java binder object will be a failure, with kernel log complain: ...got transaction to invalid handle... <b> afterward, any new bind object passed to this process will NOT create a brand new one for it, instead, it will be simply and incorrectly mapped to the above old biner object, because the new incoming one will use the same "handle value" as the old one. This will make a mess and many weird bugs. First, it may break "binder object identity" compare based functionality. For example, after registering a listener to a service, all following registering may fail because the latter new listener object is mapped to the old one incorrectly. The service will reject them as "already registered". Second, binder call on the old binder object is actually dispatched to the new remote binder object, it might even be a success if they are of the same class/interface, which is actually not we expected; and on the other hand, the new binder object may even be of different class/interface, and of course, the binder call may be a failure due to "interface descriptor check". <c> the user space process cannot recover from the bug automatically unless restart. Solution: Hold a temporary reference to the parcel object until "BC_ACQUIRE/BC_INCREFS" flushed to driver. Bug: 139327211 Test: monkey test for one day and one night Co-authored-by: Steven Moreland <smoreland@google.com> Signed-off-by: Jintao Zhu <zhujtcsieee@gmail.com> Change-Id: I9345f443996b0bdef9d57ddaad119b86205e817f
* | freezer: reentrant enable/disable methodMarco Ballesio2020-08-271-2/+12
|/ | | | | | | | | | | | | | | | | | | | the app freezer state can be toggled in multiple situations when a debugging tool like heapdump is invoked, or when system_server dumps its binder connections. All these uses are potentially concurrent and a robust method to handle reentrancy is necessary to avoid leaving the freezer in a state incompatible with a specific operation. This patch moves freezer enable and disable operations from Process to CachedAppOptimizer (ActivityManager), introduces a new ActivityManager API to centralize all freezer state changes to ActivityManager and modifies client code accordingly. Bug: 151225245 Test: manually verified that no regression are introduced on freezer behavior, verified that concurrent behavior is handled properly Change-Id: I7d588cc6e0499012dce64ed4e42ff2adb336062d Merged-In: I7d588cc6e0499012dce64ed4e42ff2adb336062d
* Disable the freezer while we're collecting binder interface descriptors.Martijn Coenen2020-04-011-0/+6
| | | | | | | | | These are synchronous calls out from system_server to many processes; make sure we don't get hung up on them. Bug: 152294322 Test: N/A Change-Id: Ie6f9da6c7f5df346cc28e0968f70a898bcd52adf
* Rename AppOpsCollector -> OnOpNotedCallbackPhilip P. Moltmann2020-03-101-1/+1
| | | | | | | | and annotate time values used by this area of code correctly. Fixes: 150699068 Test: Only renames Change-Id: Ibd5b08900d6855603e7ce59048587d391a5c5410
* Introduce thread-local allowBlocking flagDmitri Plotnikov2020-03-061-3/+8
| | | | | | | Test: see instructions in http://ag/7911739 Fixes: 146675384 Change-Id: I478f2a8c4e4d8d563e5e78f6e103a62fe120191f
* Merge "Add getExtension to android.os.IBinder interface" am: 935dfd2ce9 am: ↵Automerger Merge Worker2020-02-041-0/+4
|\ | | | | | | | | | | 84642d37d5 am: fcc3a08dd4 Change-Id: I3e36d8ab9a629377529afbb1c0276c79d3414a00
| * Add getExtension to android.os.IBinder interfaceYo Chiang2020-02-031-0/+4
| | | | | | | | | | | | | | | | | | | | Provide a mechanism to extend and customize a binder interface without having to modify the original (base) interface. See the full motivation here: aosp/1099664 Bug: 147834064 Test: atest FrameworksCoreTests:BinderTest FrameworksCoreTests:BinderProxyTest Change-Id: Idd3595b1302cf7ac0590d064e795ba0b75811af6
* | Supplying the IBinder to binderDiedSuprabh Shukla2020-01-131-3/+5
| | | | | | | | | | | | | | | | | | | | Plugging the binder instance that dies. This helps a single DeathRecipient to listen for multiple binder deaths. Test: atest FrameworksCoreTests:BinderDeathRecipientTest Bug: 135633339 Change-Id: I976ee2a138877830885ee1cbbd2b313ecb87aeb3
* | Log outgoing blocking binder calls in system server as WTFDmitri Plotnikov2019-12-121-2/+8
| | | | | | | | | | | | | | Test: boot the system, see log entries like this: 4030 E Binder : Outgoing transactions from this process must be FLAG_ONEWAY Change-Id: Ie1b3c76ec08aecc706a5edc5a6d2b4b946895ed9
* | Merge "Don't hold sProxyLock while retrieving interface descriptors." am: ↵Martijn Coenen2019-11-041-29/+30
|\| | | | | | | | | | | | | | | ef6fe13c77 am: d4d27b403c am: 3d4d4253e4 Change-Id: I27540c32f7150eff152b324c4edccc6afcce6b92
| * Don't hold sProxyLock while retrieving interface descriptors.Martijn Coenen2019-10-091-29/+30
| | | | | | | | | | | | | | | | | | | | Since we can't guarantee apps won't call back into us while calling getInterfaceDescriptor() (even though that's a *really* bad idea), don't hold any locks while doing so, to protect us from deadlocks. Bug: 140603195 Test: adb shell am dump binder-proxies Change-Id: I6289c799aa7027f80792cb751fe1dc437552ea58
* | Allow apps to collect which appops were notedPhilip P. Moltmann2019-08-301-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If private user data is send to an app the data provider should note an app-op. This change adds a new API AppOpsManager#setNotedAppOpsCollector that allows an app to get notified every time such an private data access happens. This will allow apps to monitor their own private data usage. Esp. with big, old apps, distributed teams or 3rd party libraries it might not always be clear what subsystems access private data. There are three different situations how private data can be accessed and an app op is noted: 1. Private data access inside a two-way binder call. E.g. LocationManager#getLastKnownLocation. When we start a two way binder transaction, we remember the calling uid via AppOpsManager#collectNotedAppOps. Then when the data providing code calls AppOpsManager#noteOp->AppOpsManager#markAppOpNoted the noted app-op is remembered in AppOpsManager#sAppOpsNotedInThisBinderTransaction. Then when returning from the binder call, we add the list of noted app-ops to the reply-parcel via AppOpsManager#prefixParcelWithAppOpsIfNeeded. On the calling side we check if there were any app-ops noted in AppOpsManager#readAndLogNotedAppops and then call the collector while still in the binder code. This allows the collector e.g. collect a stack trace which can be used to figure out what app code caused the private data access. 2. Very complex apps might do permissions checks internal to themself. I.e. an app notes an op for itself. We detect this case in AppOpsManager#markAppOpNoted and immediately call the collector similar to case (1). 3. Sometimes private data is accessed outside of a two-way binder call. E.g. if an app registers a LocationListener an app-op is noted each time a new location is send to the app. In this case it is not clear to the framework which app-action triggered this app-op-note. Hence the data provider has to describe in a AsyncNotedAppOp object when an why the access happened. These objects are then send to the system server via IAppOpsService#noteAsyncOp and then the collector in the app. There are rare cases where a private data access happens before the app is running (e.g. when a geo-fence is triggered). In this case we cache a small amount of AsyncNotedAppOps (in AppOpsService#mUnforwardedAsyncNotedOps) and deliver them when the app is ready for these events (in AppOpsManager#setNotedAppOpsCollector). Test: atest CtsAppOpsTestCases (includes new tests covering this functionality) Bug: 136505050 Change-Id: I96ded4a8d8d9bcb37a4555d9b1281cb57945ffa9
* | IPC StrictModeLucas Dupin2019-08-261-1/+1
|/ | | | | | | | | | | | | | This CL introduces a way of blocking IPCs on the main thread. This is enforced by StrictMode, and enabled on tests and eng builds. All current blocking IPCs were whitelisted and bugs will be filed, in order to fix them for R. Bug: 139360025 Test: adb logcat Test: atest SystemUITests Change-Id: I45af2619605ee36b6bae83ef080272c62754b654
* Fix a bug with worksource propagation.Olivier Gaillard2019-02-011-0/+9
| | | | | | | | | | | | | | | | | | | | | | It is properly added to the parcel when Binder.setCallingWorkSource is called manually, however it does not work when we call Binder.setCallingWorkSource in Binder#ProxyTransactListener. The problem is that we are adding the worksource to the parcel too early. It is called before we add the work source to the thread local (ThreadLocalWorkSource.setUid)... What currently happens - Client code calls an AIDL method - AIDL generated code calls writeInterfaceToken which add the headers to the parcel (including the worksource) - AIDL generated code calls Binder#transact - Binder#transact calls ProxyTransactListener#onTransactStarted --> this code is calling Binder.setCallingWorkSource too late. After writeInterfaceToken is called which is where the code calls Binder.getCallingWorkSource and add it to the parcel. To fix it, we udpate the parcel request headers if the work source has been fixed when the listener is called. Test: atest binderLibTest BinderWorkSourceTest BinderCallsStatsServiceTest android.os.ParcelTest BinderProxyTest Bug: 123744028 Change-Id: Id1a4565c1f096d38bf1e423bea897da77ff84005
* Restrict dumping of binder proxy info in bugreports.Martijn Coenen2018-11-261-0/+10
| | | | | | | | | | | This dumping is done with the ActivityManagerService lock held, and can take a while. Therefore, do the dumping without the lock, and only dump proxy interface counts if the number of proxies looks unreasonable to start with. Bug: 119616995 Test: boots, bugreport doesn't dump proxy interfaces with normal count Change-Id: If7ca8fbe08362db2ef57bf2e210160f37859fd79
* Adds a mechanism to listen to proxy transact method calls.Olivier Gaillard2018-10-291-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are multiple use cases for it: 1) Make it easy for another process to set the worksource. The worksource can be propagated in a thread local - this is how gmscore and soon system server works - the worksource can then be set for all binder calls using Object transactStarted() { Binder.setWorkSource(ThreadLocalWorkSourceUid.get()); return null; // No token needed. } void transactEnded() { Binder.setWorkSource(null); } This will be used by system process and gmscore. 2) SystemUI team was interested in detecting binder calls done from the main thread in dogfood/tests. This listener will make it easy to figure out which thread is used. Performance impact of transact method: - With current code: 45ns per call - With this code: 57ns per call This is not significant compared to the total binder call time which is 10-100s of microseconds. Test: unit test Change-Id: Id0a2f52cba33b390ff83f703284b79471cc80b1c
* Merge "BinderProxy dump: distinguish between empty descriptor and dead ↵Martijn Coenen2018-08-101-0/+3
|\ | | | | | | | | | | | | | | remote." am: 2e9e624c76 am: cbd295ea50 am: 23920a0da9 am: d909c7d1d0 Change-Id: Ia52ee5d128a3269c5ac34478ade5cc768cc43bb5
| * BinderProxy dump: distinguish between empty descriptor and dead remote.Martijn Coenen2018-08-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | getInterfaceDescriptor() will return an empty string when the call to retrieve it into the remote process fails. Proxies to a dead binder process then show up as having an empty descriptor in the proxy dumps, and can't be distinguished from live proxies with an empty descriptor. Instead, if we get an empty string, check if the proxy is still alive, so we can more accurately dump. This will make it much easier to find proxy leaks to dead binder nodes. Bug: 109888955 Test: adb shell dumpsys activity binder-proxies Change-Id: Ib37ec004f38c99743ffb4a62101c12626b649e5d
| * resolve merge conflicts of 80894b606303eb9320a9969c1553d14ce0220dca to ↵Martijn Coenen2018-07-241-22/+23
| | | | | | | | | | | | | | | | | | stage-aosp-master BUG: None Test: I solemnly swear I tested this conflict resolution. Change-Id: I7c36f66c4bf9129c1b421290f82bdae83be6979e Merged-In: If9dd6913868a34ea1e3d14fee1860a4ff368e06b
| * Make BinderProxy @hide public class.Martijn Coenen2018-07-221-0/+541
| | | | | | | | | | | | To make some future refactoring easier. Added some JavaDoc (mostly links to android.os.IBinder) to make checkstyle happy. Test: builds Merged-In: If9dd6913868a34ea1e3d14fee1860a4ff368e06b Change-Id: If9dd6913868a34ea1e3d14fee1860a4ff368e06b (cherry picked from commit 03e6d923c579ec79939944e7a9a8ac1b36aa2bbb)
* Move proxy debug info dumping back to Java.Martijn Coenen2018-07-171-5/+2
| | | | | | | | | | | | | This had to be called from native because serialization was done from native, but now that serialization is in Java we can move this back to a more logical place. Also, this allows us to dump the per-UID proxy counts in this situation again. Bug: 109888955 Test: sailfish builds, proxy debug info shown on hitting limits Change-Id: I4e06b3f93e30ed1c7868ec9e018709a7e796e441
* Dump top binder proxy interface names in dumpsys.Martijn Coenen2018-07-171-13/+63
| | | | | | | | To facilitate real-time debugging. Bug: 109888955 Test: builds, adb shell dumpsys activity binder-proxies shows output Change-Id: Iffcbbb824f4050b6fb8f556c8b4d09115e53da18
* Make BinderProxy @hide public class.Martijn Coenen2018-07-171-0/+541
To make some future refactoring easier. Added some JavaDoc (mostly links to android.os.IBinder) to make checkstyle happy. Test: builds Change-Id: If9dd6913868a34ea1e3d14fee1860a4ff368e06b