summaryrefslogtreecommitdiffstats
path: root/include/binder
diff options
context:
space:
mode:
authorChristopher Tate <ctate@google.com>2011-02-17 13:00:38 -0800
committerChristopher Tate <ctate@google.com>2011-02-28 11:37:20 -0800
commit71f64dd876262407ff2636827de64ccde9c2088b (patch)
tree6801442cbf9bae269af8bdfb896773f2dbe213e6 /include/binder
parent661a8c37c86d02271980fbe9fa065ace9141e430 (diff)
downloadframeworks_native-71f64dd876262407ff2636827de64ccde9c2088b.zip
frameworks_native-71f64dd876262407ff2636827de64ccde9c2088b.tar.gz
frameworks_native-71f64dd876262407ff2636827de64ccde9c2088b.tar.bz2
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
Diffstat (limited to 'include/binder')
-rw-r--r--include/binder/IBinder.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/binder/IBinder.h b/include/binder/IBinder.h
index 749a977..81b56c2 100644
--- a/include/binder/IBinder.h
+++ b/include/binder/IBinder.h
@@ -98,7 +98,7 @@ public:
* Register the @a recipient for a notification if this binder
* goes away. If this binder object unexpectedly goes away
* (typically because its hosting process has been killed),
- * then DeathRecipient::binderDied() will be called with a referene
+ * then DeathRecipient::binderDied() will be called with a reference
* to this.
*
* The @a cookie is optional -- if non-NULL, it should be a