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