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