ce92b0d070c4967914698b4e257c203d7121c972 |
|
30-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager Drop down the limit on when we log, since under normal operation we will never get more than a few K of data due to strict mode. Try to clean up the code paths coming in and out of binder IPCs to plug any places where we could disrupt the gather flag of a thread, causing it to keep gathering stack crawls (which is the thing that is causing our strict mode data to become so large). Change-Id: I9a46512283d33e863c429840b465855d1fabb74e
/frameworks/base/core/jni/android_util_Binder.cpp
|
017c6a28bee788d2ba5550548ea844d0236bc40e |
|
26-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17656716: Unhandled exception in Window Manager Create descriptive errors when sending unreasonably large parcels through IPC. Change-Id: Ie93b5372a8ed87541db282876c4eeeae69a1e8bd
/frameworks/base/core/jni/android_util_Binder.cpp
|
d1a7fca1451bf4ab7f9b704c0bace180095c2237 |
|
06-Aug-2014 |
Mathieu Chartier <mathieuc@google.com> |
Fix JNI error in exception reporting. There was a JNI error where when you got an OOM and called report_exception, it would call two NewStringUTF in a row without checking the return values. This could mean that the first one threw a new OOME and the second one would cause a JNI error when it also attempted to throw an OOME with a pending OOME. Bug: 16843627 (cherry picked from commit cf6775eece8628ac069a6d4803e7f20a017e7e62) Change-Id: Ibdc7d0e55a48b2a61a1db0868a5d77c2ae53f6f3
/frameworks/base/core/jni/android_util_Binder.cpp
|
cbefd8dd2befcb768f911a63becc427ec4c13250 |
|
14-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Battery stats more wake history, power save mode. Add new option for battery stats to record the full wake lock history, and recording the current power save mode. Also add in some additional error constants when generating Binder error exceptions. And fix issue #14974572: Avoid repeating wakeup_reason at the beginning of history Change-Id: I7c1a2ab9569de216634f63d8ad69f1294ef1d235
/frameworks/base/core/jni/android_util_Binder.cpp
|
5b6da1aee884d32d8140e27c5b5b4d16ea4a37c8 |
|
18-Apr-2014 |
Mark Salyzyn <salyzyn@google.com> |
jni: binder ptrdiff_t compile issues Change-Id: Ibdd82479d3f9fb53cf1d6793c4f7353e8f1c3646
/frameworks/base/core/jni/android_util_Binder.cpp
|
cfd91e7852bac3f9775cf3d05eedaade070cfecd |
|
18-Apr-2014 |
Mark Salyzyn <salyzyn@google.com> |
jni: binder 64-bit compile issues Change-Id: I8a3083e7e9389bbb84c2dd061fef059e0595800d
/frameworks/base/core/jni/android_util_Binder.cpp
|
8ab665dda40ab10e60fc69392022171f454af530 |
|
22-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Make Binder and Parcel 64-bit compatible Changes include [x] Long is used to store native pointers [x] Added new method obtain(long obj) to Parcel. Binder uses this method instead of obtain(int obj). [x] obtain(int) has been changed to throw unsupported operation exception. Change-Id: I408e0f2a24deb28c9277d86670653a51eb314266 Signed-off-by: Ashok Bhat <ashok.bhat@arm.com> Signed-off-by: Craig Barber <craig.barber@arm.com> Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
/frameworks/base/core/jni/android_util_Binder.cpp
|
4a72b3064cecc85c56b8d75bb4a2d9fedbf76ec8 |
|
11-Dec-2013 |
Elliott Hughes <enh@google.com> |
Merge "fix possible buffer overrun and memory leak"
|
44bc18664985e845a2299f20b6392d378fad8b4d |
|
24-Jul-2013 |
Colin Cross <ccross@android.com> |
replace cutils/logger.h with log/logger.h and remove it from files that don't use it. Change-Id: Ieb44a3f1f75c2d2b277f0d01ca926a92211e3fe6
/frameworks/base/core/jni/android_util_Binder.cpp
|
ec3d44cc7e5308cbfb166166da939a5b5ad216bc |
|
21-Dec-2012 |
Sungmin Choi <sungmin.choi@lge.com> |
fix possible buffer overrun and memory leak Use snprintf instead of sprintf and fclose() before return. Change-Id: I3ed193464cc0dc90e9935ae19162667ad367628b
/frameworks/base/core/jni/android_util_Binder.cpp
|
2b4d22cda3c44f5d731c15306b85045417071408 |
|
26-Apr-2013 |
Jeff Sharkey <jsharkey@android.com> |
Disable various sampling event logs. They're unused at the moment. Change-Id: Ib629b405e7b6666d38fcd0ebaa16490bfb0e95f0
/frameworks/base/core/jni/android_util_Binder.cpp
|
a4ca8ea0ad14c509d1ced46482e83c1b8a518982 |
|
03-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Fix reference cycle in InputEventReceiver and Sender. If the receiver or sender was not properly disposed, then the underlying input channel might be leaked because the native peer was holding a strong reference to the object. Switched to using a weak reference. Also updated Binder to use a new helper created for this purpose. Change-Id: I19680bf96d0548777bff02aa1d91874d1e8e41da
/frameworks/base/core/jni/android_util_Binder.cpp
|
b1d90c8f60f71422196c337f1d078b68867f5710 |
|
07-Mar-2013 |
Mathias Agopian <mathias@google.com> |
fix JNI use of incStrong/decStrong Change-Id: Ia11b404dea483dc19bbc30f4d7bcff516655e180
/frameworks/base/core/jni/android_util_Binder.cpp
|
4120375d46091df8527bb701882e056fbb0e6b06 |
|
31-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Remove Binder.getOrigCallingUid(). Replaced all remaining places that used it with explicit user specification. While doing this, I ran into stuff that was creating PendingIntent objects (that now need to specify the explicit user they are for), which are also posting notifications... but have no way to specify the user for the notification. So the notification manager in the system process now also gets a formal concept of a user associated with the notification, which is passed in to all the necessary aidl calls. I also removed the old deprecated aidl interface for posting/cancelling notifications, since we now always need a user supplied. There is more work that needs to be done here, though. For example I think we need to be able to specify USER_ALL for a notification that should be shown to all users (such as low storage or low battery). Along with that, the PendingIntent creation needs to be tweaked to be able to handle USER_CURRENT by evaluating the user at the point the pending intent is sent. That's for another change, however. Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
/frameworks/base/core/jni/android_util_Binder.cpp
|
a53de0629f3b94472c0f160f5bbe1090b020feab |
|
09-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Add callback hack to find out when to load system properties. Use this to reload the trace and layout bounds properties. This is ONLY for debugging. Change-Id: I1c4bdb52c823520c352c5bac45fa9ee31160793c
/frameworks/base/core/jni/android_util_Binder.cpp
|
d84e1ce0b535128f03416145554fb405f9fade3e |
|
07-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Split Parcel JNI details away from Binder. This is purely a refactoring, with no change to the underlying functionality. Change-Id: I41b59f14e57d1cc144274a01f77658d99a1bfe02
/frameworks/base/core/jni/android_util_Binder.cpp
|
742a67127366c376fdf188ff99ba30b27d3bf90c |
|
04-May-2011 |
Amith Yamasani <yamasani@google.com> |
Multi-user - 1st major checkin Switching activity stacks Cache ContentProvider per user Long-press power to switch users (on phone) Added ServiceMap for separating services by user Launch PendingIntents on the correct user's uid Fix task switching from Recents list AppWidgetService is mostly working. Commands added to pm and am to allow creating and switching profiles. Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
/frameworks/base/core/jni/android_util_Binder.cpp
|
3762c311729fe9f3af085c14c5c1fb471d994c03 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/#/c/157220 Bug: 5449033 Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/base/core/jni/android_util_Binder.cpp
|
8564c8da817a845353d213acd8636b76f567b234 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGW(_IF) to (IF_)ALOGW(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/157065 Bug: 5449033 Change-Id: I00a4b904f9449e6f93b7fd35eac28640d7929e69
/frameworks/base/core/jni/android_util_Binder.cpp
|
6215d3ff4b5dfa52a5d8b9a42e343051f31066a5 |
|
04-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGI(_IF) to (IF_)ALOGI(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/156801 Bug: 5449033 Change-Id: Ib08fe86d23db91ee153e9f91a99a35c42b9208ea
/frameworks/base/core/jni/android_util_Binder.cpp
|
5baa3a62a97544669fba6d65a11c07f252e654dd |
|
20-Dec-2011 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/156016 Bug: 5449033 Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
/frameworks/base/core/jni/android_util_Binder.cpp
|
fe2d4abdd917aa98baf56d4b903999c2d8b68a7d |
|
10-Nov-2011 |
Jeff Brown <jeffbrown@google.com> |
am 698d3de6: am e7de36e6: Merge "Throw TransactionTooLargeException when Binder transaction fails. Bug: 5578022" into ics-mr1 * commit '698d3de681bf85047675baa61f9b28961f3d6862': Throw TransactionTooLargeException when Binder transaction fails. Bug: 5578022
|
0bde66a837542e5bd901d8b8e47c5bd7c4c99fe4 |
|
07-Nov-2011 |
Jeff Brown <jeffbrown@google.com> |
Throw TransactionTooLargeException when Binder transaction fails. Bug: 5578022 Previously, Binder transactions failed silently, which caused problems because apps would carry on assuming that the operation had succeeded. Often, the apps would crash soon due to a violated invariant, but sometimes they managed to do some damage first... Change-Id: Ia9cc98b3b761a8160e7c4e87507860b5912c0451
/frameworks/base/core/jni/android_util_Binder.cpp
|
71f2cf116aab893e224056c38ab146bd1538dd3e |
|
20-Oct-2011 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGV(_IF) to (IF_)ALOGV(_IF) DO NOT MERGE See https://android-git.corp.google.com/g/#/c/143865 Bug: 5449033 Change-Id: I0122812ed6ff6f5b59fe4a43ab8bff0577adde0a
/frameworks/base/core/jni/android_util_Binder.cpp
|
c04db7e06737c5b9bae276ac462858d44002672e |
|
04-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix handling of "allow fds" state. Didn't take into account nesting of bundles. Boo. Change-Id: Ic8cf21ad8d6f4938a3e105128624c9d162310d01
/frameworks/base/core/jni/android_util_Binder.cpp
|
9ecebbfbf768fd63e9a6c9a09c86d81c7737ee2d |
|
29-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Add mechanism for Parcel to not allow FDs to be written to it. This is to help implement issue #5224703. Change-Id: I026a5890495537d15b57fe61227a640aac806d46
/frameworks/base/core/jni/android_util_Binder.cpp
|
0d4a792e8d5ebfd182acc8db7cd9b40f3bc51640 |
|
30-Aug-2011 |
Christopher Tate <ctate@google.com> |
Fix JNI for warning about failure to unlink DeathRecipients We now (a) use the right Class getName() method, and (b) look it up once at setup time rather than doing that lookup every time we want to emit the warning. Verified to work properly and no longer crash or throw or otherwise complain. Change-Id: If0767f8845588ba7f34bac21474f4e2ad5c111d6
/frameworks/base/core/jni/android_util_Binder.cpp
|
ac5e350e567c7a257ced37dd4e8ca0f4c95f7e81 |
|
26-Aug-2011 |
Christopher Tate <ctate@google.com> |
Warn if we're tearing down "live" DeathRecipient content [take 2] If the native-side bookkeeping still has strong references to VM-side DeathRecipient objects at the time when it's being torn down, that suggests that the app is doing unwholesome. Log a warning to that effect, with the class name of the objects to try to help the developer figure out what they're mishandling. Fixes bug 5202777 -- in particular, it no longer logs in the working-as-intended case following delivery of the death notices, when we've got the existing list shell but the weak refs have properly cleared. Also step down from "error" to "warning" logging as befits the nature of the actual situation now being described. This new patch fixes the JNI bug present in the earlier version. Change-Id: I095862777a8d0e3905cb7f416af658878280041d
/frameworks/base/core/jni/android_util_Binder.cpp
|
055fa08abfe5b8edbdc37b87d0138b8ba8d975f5 |
|
25-Aug-2011 |
Guang Zhu <guangzhu@google.com> |
Revert "Warn only if we're tearing down "live" DeathRecipient content" This reverts commit 2611f89ab4f1119b96123edb2cd6d8d8139c03c4
/frameworks/base/core/jni/android_util_Binder.cpp
|
2611f89ab4f1119b96123edb2cd6d8d8139c03c4 |
|
24-Aug-2011 |
Christopher Tate <ctate@google.com> |
Warn only if we're tearing down "live" DeathRecipient content If the native-side bookkeeping still has strong references to VM-side DeathRecipient objects at the time when it's being torn down, that suggests that the app is doing unwholesome. Log a warning to that effect, with the class name of the objects to try to help the developer figure out what they're mishandling. Fixes bug 5202777 -- in particular, it no longer logs in the working-as-intended case following delivery of the death notices, when we've got the existing list shell but the weak refs have properly cleared. Also step down from "error" to "warning" logging as befits the nature of the actual situation now being described. Change-Id: Ic393560824800fbd912a6e69692c65be4fcc7544
/frameworks/base/core/jni/android_util_Binder.cpp
|
86284c60b52c40f027427aa32dbe8dc0899b63d5 |
|
18-Aug-2011 |
Christopher Tate <ctate@google.com> |
Stop leaking DeathRecipient and BinderProxy instances The native-side death recipient object holds a global reference to the DVM-side DeathRecipient instance. This is necessary so that the DeathRecipient isn't GC'd early in the case when the caller of linkToDeath() doesn't retain their own reference to the recipient instance. However, that global reference was never being released in association with the delivery of the actual binderDied() event. In that case, if the death recipient did not explicitly call unlinkToDeath() themselves, the hard global reference was maintained and a hard-reference cycle was perpetuated, crossing the native <-> DVM boundary. This was visible as a gradual leakage of DVM-side DeathRecipient and BinderProxy instances. The one problematic constraint is that it needs to be valid to call unlinkToDeath() cleanly *after* binderDied() is delivered to the given recipient; that requires that we have the hard reference linkage described above. The fix is to replace the hard global reference with a weak reference to the DVM-side DeathRecipient after we deliver binderDied() to that recipient. In the case where the caller has retained their own reference to the instance (i.e. they might still call unlinkToDeath() on it later), the weak reference stays live and everything works cleanly (and is reaped explicitly by unlinkToDeath() as usual). In the case where the caller has *not* retained the instance to call unlinkToDeath() themselves, demoting to a weak DeathRecipient reference allows the DeathRecipient to be GC'd, which in turn frees the DVM-side BinderProxy it's tied to, and so on around the chain to free all of the associated allocations. Fixes bug 5174537 Change-Id: Ia4ad76e667140cc2a1b74508bbba652ab31ab876
/frameworks/base/core/jni/android_util_Binder.cpp
|
9013ccd9fcf3ac317e122aff08cb27cdac2b95fe |
|
26-Apr-2011 |
Bjorn Bringert <bringert@android.com> |
Check for exceptions before calling back into Java This fixes a crash when StrictMode is on and a Binder call throws an exception. Bug: 4337406 Change-Id: I5c4d4a8bcd92aa5b0d72b7957578df980cb2a783
/frameworks/base/core/jni/android_util_Binder.cpp
|
a3804cf77f0edd93f6247a055cdafb856b117eec |
|
12-Apr-2011 |
Elliott Hughes <enh@google.com> |
You don't need to poke around inside FileDescriptor manually. We can help you with that. Note also that getParcelFileDescriptorFD did no such thing. All its callers were passing in a regular java.io.FileDescriptor and expecting the int. No ParcelFileDescriptors involved. Change-Id: Idc233626f20c092e719f152562601f406cc1b64a
/frameworks/base/core/jni/android_util_Binder.cpp
|
69a017bc1d1649350f830dfada5c6ed5eac0b770 |
|
08-Apr-2011 |
Elliott Hughes <enh@google.com> |
More JNI exception-throwing cleanup. There are a few (unimportant) bug fixes here. There were several attempts to throw exceptions in situations where there's already a pending exception. There were also cases where the code was wrong; it was checking for a NULL return from Get*ArrayElements and throwing NPE, but passing NULL is an error that causes a crash and a NULL return means an exception has already been thrown. I didn't want to get into the Scoped* classes just yet, but that was by far the easiest way to fix this. Change-Id: I0b31160ee51b96e82539f6514b8412b149dba7c3
/frameworks/base/core/jni/android_util_Binder.cpp
|
e17aeb31030cfeed339a39a107912ad5e9178390 |
|
08-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Improve activity manager debug dumps. Activity manager now does all dump requests into apps asynchronously, so it can nicely timeout if there is an app problem. Also lots of general cleanup of the am dump output. Change-Id: Id0dbccffb217315aeb85c964e379833e6aa3f5af
/frameworks/base/core/jni/android_util_Binder.cpp
|
f58f041beb8a00db201eb3c8eb801dc1b702253d |
|
15-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
am cffde30f: am 44220a56: Merge "Add some debug code to try to track down issue 3183612" into gingerbread * commit 'cffde30fc10ecdfca53877fbee61525028eb47ba': Add some debug code to try to track down issue 3183612
|
cf3004a46eabb49f3eee483067e75aef7b0a69e7 |
|
14-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Add some debug code to try to track down issue 3183612 java.lang.SecurityException: Neither user 1209 nor current process has android.permission.WAKE_LOCK. Change-Id: I3e84f8795941744e697824a5e5b2e651f565b253
/frameworks/base/core/jni/android_util_Binder.cpp
|
79dd31f73d8ca4432d6f83bef1221cc3e93e932c |
|
05-Mar-2011 |
Christopher Tate <ctate@google.com> |
Don't fail unlinking death recipients on dead binders It's legal to call unlinkToDeath() *after* receiving binderDied(), as long as the recipient being unlinked was in fact linked previously. Don't throw an exception in this case. (The exception was going unhandled in the system process, bringing down the runtime. That's bad.) The change here is a bit subtle. In the new implementation, the lifetime of a JavaDeathRecipient -- the fundamental bridge between IBinder objects and the Dalvik/JNI world -- is tied to the lifetime of the Dalvik-side BinderProxy object it's associated with. That means it's inappropriate for the JavaDeathRecipient to disappear [for purposes of being referenced from the Dalvik side] just because the IBinder has sent out its obituaries, and instead the JavaDeathRecipient objects are kept around until the Dalvik-side client code actually drops its reference to the BinderProxy. This boils down to a one-line change: we no longer unpin the JavaDeathRecipients and free them immediately in response to binderDied(). The rest of the CL is #ifdefed-out debugging that is invaluable when bugs crop up. Bug 3513703 Change-Id: I743fa49669c9252f71dcabfd8dcf42ed729b70a5
/frameworks/base/core/jni/android_util_Binder.cpp
|
bd8b6f25bb48daea4aeb0c7463661c8e69baece0 |
|
01-Mar-2011 |
Christopher Tate <ctate@google.com> |
Fix binder proxy death notice tracking There was an issue with stale recipient tracking when BinderProxy weak references had been purged and a new proxy object allocated for a still-live underlying IBinder. The death recipient bookkeeping has now been reworked so that it's fundmentally tied to the BinderProxy instances, not maintained as global state, to prevent this sort of confusion entirely. Bug 3499939 Change-Id: I75c5216b6d53b90868ac969e32c9725201e51be3
/frameworks/base/core/jni/android_util_Binder.cpp
|
c9119f5034d36f548bbddd8f60291e24ab4e270b |
|
01-Mar-2011 |
Dianne Hackborn <hackbod@google.com> |
Add ParcelFileDescriptor APIs to get raw fd. Change-Id: I66ba72ffffd27237e60c9411453eef950ae62705
/frameworks/base/core/jni/android_util_Binder.cpp
|
20ccb06a7c7fe368901c07b4acc70ad6513714cd |
|
01-Mar-2011 |
Elliott Hughes <enh@google.com> |
Merge "Fix Parcel.writeNative to not ignore 'offset'."
|
a28b83ee04ca25100781f37a50665d6e1b05e3a2 |
|
28-Feb-2011 |
Elliott Hughes <enh@google.com> |
Fix Parcel.writeNative to not ignore 'offset'. Also switch to using libcore's array bounds checking. (This variant had no detail message and was missing the length check.) Bug: http://code.google.com/p/android/issues/detail?id=15075 Change-Id: Icfc045bd59403b59f02d95c8514abf881d3996e5
/frameworks/base/core/jni/android_util_Binder.cpp
|
0b41448506610f73302cc631677823fd8b865ea5 |
|
17-Feb-2011 |
Christopher Tate <ctate@google.com> |
Binder linkage no longer depends on JNI objrefs as persistent tokens There are two areas that have changed to eliminate the assumption that local jobject references are both canonical and persistent: 1. JavaBBinderHolder no longer holds onto and reuses it parent object reference per se. Since the underlying JavaBBinder object holds a real global ref, this was redundant anyway. Now, for purposes of its transient need to perform JNI operations, it simply uses the current jobject ref(s) passed during method invocation, and no longer attempts to hold these refs beyond the scope of a single invocation. 2. Binder obituaries no longer assume that a jobject reference to a recipient will always compare == as a 32-bit value with any future reference to the same object. The implementation now asks Dalvik whether object references match. This amended patch fixes the earlier bug around races between remote binder death cleanup and local explicit unregistration of VM-side death recipients. Bug 2090115 Change-Id: I70bd788a80ea953632b1f466f385ab6b78ef2913
/frameworks/base/core/jni/android_util_Binder.cpp
|
e2ed9562fc6c88dfdeb924063f5d0ccea1912754 |
|
25-Feb-2011 |
Christopher Tate <ctate@google.com> |
Revert "Binder linkage no longer depends on JNI objrefs as persistent tokens" This reverts commit c2d55dd89743c8a38deb809f3cdf1ad2d1dbac2b.
/frameworks/base/core/jni/android_util_Binder.cpp
|
c2d55dd89743c8a38deb809f3cdf1ad2d1dbac2b |
|
17-Feb-2011 |
Christopher Tate <ctate@google.com> |
Binder linkage no longer depends on JNI objrefs as persistent tokens There are two areas that have changed to eliminate the assumption that local jobject references are both canonical and persistent: 1. JavaBBinderHolder no longer holds onto and reuses it parent object reference per se. Since the underlying JavaBBinder object holds a real global ref, this was redundant anyway. Now, for purposes of its transient need to perform JNI operations, it simply uses the current jobject ref(s) passed during method invocation, and no longer attempts to hold these refs beyond the scope of a single invocation. 2. Binder obituaries no longer assume that a jobject reference to a recipient will always compare == as a 32-bit value with any future reference to the same object. The implementation now asks Dalvik whether object references match. Bug 2090115 Change-Id: If62edd554d0a9fbb2d2977b0cbf8ad7cc8e2e68d
/frameworks/base/core/jni/android_util_Binder.cpp
|
0234376503ce421c4b871d5d811c541f5094301a |
|
31-Aug-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Don't propagate StrictMode over one-way Binder calls. This was causing stack stitching problems where a one-way call with violations followed by a two-way call without violations was getting the previous one-way call's violation stack stitched on to the second caller's stack. The solution is a little more indirect than I would've liked (preserving the binder's onTransact flags until enforceInterface) but was seemingly necessary to work without changing the AIDL compiler. It should also be sufficiently cheap, since no new calls to thread-local IPCThreadState lookups were required. The additional work is just same-thread getter/setters on the existing IPCThreadState. Change-Id: I4b6db1d445c56e868e6d0d7be3ba6849f4ef23ae
/frameworks/base/core/jni/android_util_Binder.cpp
|
7bcad8a315f12bd6251a998781efac7b11c2ca84 |
|
27-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Replace several IPCThreadState::get() lookups with one. Also, make StrictMode's ThreadLocal final. Change-Id: I08d400ed254fa67bb7a3dae1227f205a54c00df0
/frameworks/base/core/jni/android_util_Binder.cpp
|
727de40c6bc7c6521a0542ea9def5d5c7b1c5e06 |
|
08-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
More StrictMode work, keeping Binder & BlockGuard's thread-locals in-sync. Change-Id: Ia67cabcc17a73a0f15907ffea683d06bc41b90e5
/frameworks/base/core/jni/android_util_Binder.cpp
|
5348c014129b766d621ef82a6e42007009ffc310 |
|
25-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Better fix for gettid() sim-eng breakage from last night. Change-Id: I2e8762d43b3c224a2e102ff82fc79072a85bb4c6
/frameworks/base/core/jni/android_util_Binder.cpp
|
ad8fd282dde705ad090b2ecdc5b363df399230ab |
|
25-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Hopefully fix the sim-eng build, part 2. This is kinda gross, but I can't find a good way to check for the existence of gettid(), except by finding its syscall number. Then might as well just use it rather than hope gettid's around, as it's not in sim-eng. Change-Id: Ieb7b39426dec08bd715b6fe1a9ab5b2801bdf775
/frameworks/base/core/jni/android_util_Binder.cpp
|
8f26b323d8f78c6a183e74c464864ef7da457267 |
|
25-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Try to fix sim build. Looks like gettid() is in unistd.h. Change-Id: Ib1ecea86246ad75b2553b0ccc8ce03a53ffdf218
/frameworks/base/core/jni/android_util_Binder.cpp
|
2c5da313dd72c284fbc2c11839f8a452ab5ce574 |
|
25-Mar-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Log blocking Binder calls to the EventLog. This mimics what we do already for SQLiteDatabase's db_operation and ContentProvider's content_query_operation and content_update_operation: over a threshold things are always logged, and under which they're sub-sampled. Change-Id: Ia0280b9b07b336ee88b17be2a31a7af0fd7c5770
/frameworks/base/core/jni/android_util_Binder.cpp
|
582763ae4e2910b4059dccdfd30a447e9fc974d5 |
|
25-Mar-2010 |
Jeff Brown <jeffbrown@google.com> |
Ensure Binder finalizer handles partially initialized instances. If the Binder is allocated but its constructor does not run for some reason, then Binder.init() will not be called. Since the object was allocated, it is still eligible for finalization. Eventually when the finalizer runs and calls Binder.destroy(), it will have a NULL binder holder pointer. Previously this would cause Binder.destroy() to attempt to decrement a reference count on a NULL pointer. Now we check and ignore the binder if it does not have a valid holder pointer. Bug: b/2533956 Change-Id: Ifc2729b2f2abe8bceea5a0645ae0a4c1575b7846
/frameworks/base/core/jni/android_util_Binder.cpp
|
887f355f99ff83d568ef2885a4fdcaae475583df |
|
08-Dec-2009 |
Dianne Hackborn <hackbod@google.com> |
Propagate background scheduling class across processes. This is a very simply implementation: upon receiving an IPC, if the handling thread is at a background priority (the driver will have taken care of propagating this from the calling thread), then stick it in to the background scheduling group. Plus an API to turn this off for the process, which is used by the system process. This also pulls some of the code for managing scheduling classes out of the Process JNI wrappers and in to some convenience methods in thread.h.
/frameworks/base/core/jni/android_util_Binder.cpp
|
0795272aa226f4e965968a03daddc53ce30b7cda |
|
20-May-2009 |
Mathias Agopian <mathias@google.com> |
move libbinder's header files under includes/binder
/frameworks/base/core/jni/android_util_Binder.cpp
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android_util_Binder.cpp
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/jni/android_util_Binder.cpp
|
076357b8567458d4b6dfdcf839ef751634cd2bfb |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@132589
/frameworks/base/core/jni/android_util_Binder.cpp
|
3dec7d563a2f3e1eb967ce2054a00b6620e3558c |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@137055
/frameworks/base/core/jni/android_util_Binder.cpp
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/jni/android_util_Binder.cpp
|