History log of /frameworks/base/core/jni/android_util_Binder.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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
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