History log of /frameworks/native/libs/binder/IPCThreadState.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5ee2c9d20c0fbecf6b4a482eb8d8bfdf85d0d424 30-Sep-2014 Dianne Hackborn <hackbod@google.com> Work on issue #17656716: Unhandled exception in Window Manager

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

We now take care of saving and restoring this state in the core
IPC code path, not at the Java layer.

Change-Id: I73d564778da127bdce00f304225930e7f2318293
317ff37cf79d31170fa7320f0ba5ded1ec043e4c 29-May-2014 Mark Salyzyn <salyzyn@google.com> binder: rm utils/Debug.h

Change-Id: I16931919a26c16a0d701771c93fa7fe1c6f60ef8
07fd0f195db6d341cab4e54257f508d802c98832 19-Feb-2014 Arve Hjønnevåg <arve@android.com> Binder: Fix some valgrind errors.

When using 64 bit binder pointers, only initializing the 32 bit
handle, in a stack allocated struct, will pass uninitialized stack
data to the kernel and other processes.

Change-Id: I3432d9d36bb251d8ddb0a863661aeb80aabb3d92
87b30d0447829167b2d83f4f61f702638d937524 19-Feb-2014 Arve Hjønnevåg <arve@android.com> Binder: Don't cast directly from a pointer to binder_uintptr_t

When using the 64 bit binder interface from a 32 bit process the
pointer may get sign extended and cause the kernel to fail to read
from it.

Change-Id: I90fcf53880e2aa92e230a9723f9b3f7696170e32
11cfdccfd3cfceb08732909a1489419ff0229694 15-Feb-2014 Arve Hjønnevåg <arve@android.com> Binder: Disable attemptIncStrongHandle

The driver does not support BC_ATTEMPT_ACQUIRE and will return an error.
IPCThreadState does not handle driver errors, and will resend the failed
command blocking all other commands.

Change-Id: I643986037341821b27b62dc82df933844f4842b8
6f4f3ab36c5ed1df84eb3a9f7475f0ac42952f58 06-Feb-2014 Colin Cross <ccross@android.com> binder: fix all warnings

Fix warnings related to casting pointers to ints, using %d or %ld to
print size_t/ssize_t, and unused parameters.

Change-Id: I7a13ba83d402952989c1f795cd9e880a95b98d9e
84e625ac1e01f5a9c3ed16664da6498212ed662b 29-Jan-2014 Arve Hjønnevåg <arve@android.com> Binder: Use 64 bit pointers in 32 processes if selected by the target

Uses new kernel header where void * has been replaced by binder_uintptr_t

Change-Id: Icfc67c2a279269f700343bd9246fd7cb94efe2c1
f683e0163a84d93448b9388126902242367cd961 05-Nov-2013 Serban Constantinescu <serban.constantinescu@arm.com> Binder: Make binder portable

Changes include
- Binder attempts to cast pointers to a int datatype
which is not sufficient on a 64-bit platform.

- This patch introduces new read/write functions into
Parcel that allow pointers to be written using the
uintptr_t datatype for compile-time data type size

- Change access specifier for the methods above.

- Binder uses the 64bit android_atomic_release_cas64
(aka cmpxchg)

Change-Id: I595280541e0ba1d19c94b2ca2127bf9d96efabf1
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
ada11c5e67cf8587ad3b53dd99c27455ef26291f 13-Jul-2013 Jeff Brown <jeffbrown@google.com> Make getCallingUid/Pid const.

Change-Id: I1853b21eaa45d85274189dfd72f73fec48d0d6b7
8d96cab8bfc1b40a8e05c6f43b485750a5ae0a52 26-Jun-2013 Todd Poynor <toddpoynor@google.com> binder: add polling / single-threaded operation

This is currently safe to do only for processes that disallow any binder
threads to be created: setThreadPoolMaxThreadCount(0).

Change-Id: I8a27f3cf26f4d51edb7f222af487ac256cbcab65
fc1f308ca1d679f9e9823a848e6396a23513f2fb 12-Jun-2013 Jeff Tinker <jtinker@google.com> am de836890: am ef07386e: Prevent IPCThreadState::joinThreadPool from spinning on unexpected error

* commit 'de836890abc7b5381e285833052375cbb85730cb':
Prevent IPCThreadState::joinThreadPool from spinning on unexpected error
ef07386e2fca73680214ececc3c9c0ecbb0f6d88 11-Jun-2013 Jeff Tinker <jtinker@google.com> Prevent IPCThreadState::joinThreadPool from spinning on unexpected error

Adds logging to help determine what is happening to the /dev/binder
fd and dump the process state when it happens.

bug: 8912673
Change-Id: I2aa0c66fc499e91e0bf9ee4ae20404bec35adc82
002e1e58dfe19dd3e49a59c6827cbf51573941a2 07-May-2013 Mathias Agopian <mathias@google.com> libutils clean-up

Change-Id: I6ff4cfc736751de2912c697f954e45e275f2d386
0bed1f541d5a8284691d2296754604cde0723787 07-Oct-2012 Dave Burke <daveburke@google.com> Revert "ugly, temporary, workaroung for a problem where a binder thread spins forever"

This reverts commit 0845d0245e09548110cacb0f20e9934753388aab

Change-Id: I395037cb9427cd11f7de6bb78fbdfa917fc6263a
0845d0245e09548110cacb0f20e9934753388aab 06-Oct-2012 Mathias Agopian <mathias@google.com> ugly, temporary, workaroung for a problem where a binder thread spins forever

Bug: 7289992
Change-Id: I0c3d482a1af57e5f444be2ba7f2751ac3e954af2
8210185fe337ca9d5b01f2bff8590ea60984c31e 31-Aug-2012 Dianne Hackborn <hackbod@google.com> No longer need "original calling uid".

Change-Id: Ifc4a89dd088609a5a8553f6ac6553174e09e8222
db1597a98958b78dc0d8eced19ae1406382b70d6 17-Feb-2011 Johannes Carlsson <johannes.carlsson.x@sonyericsson.com> Fix shutdown sequence to avoid SIGSEGV when running am command

When the app_process is shutting down the main thread will close the
binder fd while pool threads are executing an ioctl (in
IPCThreadState::stopProcess called by AppRuntime::onStarted in

The binder driver will then return all pending calls in ioctl
without any error and with a command. One of the threads gets a
BR_SPAWN_LOOPER which will create a new thread (the other thread
gets a BR_NOOP). This new thread then calls
vm->AttachCurrentThread. Usually this results in a log entry with
"AndroidRuntime: NOTE: attach of thread 'Binder Thread #3' failed",
but sometimes it also causes a SIGSEGV. This depends on the timing
between the new thread an the main thread that calls DestroyJavaVM
(in AndroidRuntime::start).

If IPCThreadState.cpp is compiled with "#define LOG_NDEBUG 0" the
pool thread will loop and hit the
ALOG_ASSERT(mProcess->mDriverFD >= 0) in

Crashes like this has been seen when running the am command and
other commands that use the app_process.

This fix makes sure that any command that is received when the driver
fd is closed are ignored and IPCThreadState::talkWithDriver instead
returns an error which will cause the pool thread to exit and detach
itself from the vm. A check to avoid calling ioctl to a fd with -1
was also added in IPCThreadState::threadDestructor.

Another solution might be to change the binder driver so that it
returns an error when the fd is closed (or atleast not a
BR_SPAWN_LOOPER command). It might also be possible to call exit(0)
which is done when System.exit(0) is called from java.

Change-Id: I3d1f0ff64896c44be2a5994b3a90f7a06d27f429
a26e1cfbbcb7dc5e0b1cd79a815362d6a048ef26 16-Mar-2012 Glenn Kasten <gkasten@google.com> Scheduling group cleanup

Remove C++ APIs androidSetThreadSchedulingGroup and
androidGetThreadSchedulingGroup, and the ANDROID_TGROUP_* constants.

Former callers of these should now use the C APIs set_sched_policy and
get_sched_policy, and the SP_* constants.

Note: debug.sys.noschedgroups is not supported by the C APIs,
this needs to be discussed.

Change-Id: I32bbfc539ef4090faf9ef0320380e8cca9eae07c
4bcb57502c5a7da53ef84228aceeffb54d36e06b 06-Mar-2012 Glenn Kasten <gkasten@google.com> Remove obsolete references to sched_policy.h

As part of scheduling policy cleanup, remove or isolate
all references to the scheduling policy APIs.

Change-Id: Ia1ea2fe711a399039f25217309e061267744b856
4e975bb488bb3947703e95cb33a4838adda680f7 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
6726347e8950d34ae162fb8d6a3680a871d359e2 09-Jan-2012 Steve Block <steveblock@google.com> Rename LOG_ASSERT to ALOG_ASSERT DO NOT MERGE

See https://android-git.corp.google.com/g/157519

Bug: 5449033
Change-Id: I8ceb2dba1b031a0fd68d15d146960d9ced62bbf3
a19954ab377b46dbcb9cbe8a6ab6d458f2e32bca 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
a63ee4c2fdc4869fd1169d22e79ae9f1220c5bdb 02-Dec-2011 Ben Cheng <bccheng@google.com> am f1a4c48b: am e21dabf6: Merge "Initialize bwr.read_buffer in IPCThreadState::talkWithDriver." into ics-mr1

* commit 'f1a4c48b886d53e2afceb0620215e3792af79fd5':
Initialize bwr.read_buffer in IPCThreadState::talkWithDriver.
d640f89205e17d9f19b11c2954862f0945a40e7b 02-Dec-2011 Ben Cheng <bccheng@google.com> Initialize bwr.read_buffer in IPCThreadState::talkWithDriver.

I/valgrind( 1309): ==1310== Syscall param
ioctl(BINDER_WRITE_READ).read_buffer points to uninitialised byte(s)
I/valgrind( 1309): ==1310== at 0x480E670: __ioctl (__ioctl.S:10)
I/valgrind( 1309): ==1310== Address 0xbda651b4 is on thread 1's stack

Change-Id: I02893df7b5786b6b2dbd9659f5706d7171295ab2
9f760150f6e0f39b9923cfdc875373606839ee00 12-Oct-2011 Steve Block <steveblock@google.com> Rename (IF_)LOG() to (IF_)ALOG() DO NOT MERGE

See https://android-git.corp.google.com/g/#/c/141576

Bug: 5449033
Change-Id: I42575e7c29cf1c0f465c357a5c97ab118df6f473
aefc9cda45adb00ec1cb2c8fbd03c50fd48499fb 31-Aug-2011 Andy McFadden <fadden@android.com> Resurrect verbose binder logging

Updated the command name lists, and masked off the additional bits in
the command word when doing the name lookup.

Made descriptor values easier to grep for and consistent with kernel
output (i.e. decimal rather than hex). Attempt to show transaction
descriptors as such (they're in a union with a pointer).

Also, the writeLines() function in Static was using a no-op
logging call to write an iovec. It looks like all callers are using
N=1, so I just added a log for the first string.

Bug 5155269

Change-Id: I417b8d77da3eb6ee1d2069ba94047210f75738bc
d547432f98889d57a8c37e91090664efe63da436 21-Apr-2011 Evgeniy Stepanov <eugenis@google.com> Make sure binder ioctl structs don't contain uninitialized values.

Change-Id: I8a678f91262417bb120e65e32c244ce1512b46c2
1b6084354710ca52c04ea361d751d19174802d57 14-Dec-2010 Brad Fitzpatrick <bradfitz@android.com> Framework-side support for Dalvik "isSensitiveThread" hook.

Used in lock contention stats.

Bug: 3226270
Change-Id: Ie6f58d130a29079a59bdefad40b80304d9bc3623
67f78c4fe8f89b52199f509f36e42df0b1cdfe2d 24-Sep-2010 Dianne Hackborn <hackbod@google.com> Some debugging support.

- New feature to "am monitor" to have it automatically launch
gdbserv for you when a crash/ANR happens, and tell you how to
run the client.

- Update dumpstate to match new location of binder debug logs

- Various commented out logs that are being used to track down

Change-Id: Ia5dd0cd2df983a1fc6be697642a4590aa02a26a5
5273603e98d2db3bac656b7bcf5352c04c86d62f 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

Change-Id: I4b6db1d445c56e868e6d0d7be3ba6849f4ef23ae
a877cd85b5a026384542e3271fc310d6a8fe24c6 08-Jul-2010 Brad Fitzpatrick <bradfitz@android.com> More StrictMode work, keeping Binder & BlockGuard's thread-locals in-sync.

Change-Id: Ia67cabcc17a73a0f15907ffea683d06bc41b90e5
702ea9d42f52fc145090c0f0bfbe64993e4b8b33 18-Jun-2010 Brad Fitzpatrick <bradfitz@android.com> Start of work on passing around StrictMode policy over Binder calls.

This is (intendend to be) a no-op change.

At this stage, Binder RPCs just have an additional uint32 passed around
in the header, right before the interface name. But nothing is actually
done with them yet. That value should right now always be 0.

This now boots and seems to work.

Change-Id: I135b7c84f07575e6b9717fef2424d301a450df7b
440fd870b20b4720e11c9ea71d2a3284f8cf2f59 19-Mar-2010 Christopher Tate <ctate@google.com> Ensure that binder incalls to the system process keep the fg cgroup

On binder incalls, the handler thread is given the caller's priority by the
driver, but not the caller's cgroup. We have explicit code that sets the
handler's cgroup to match the caller's, *except* that the system process
explicitly disables this behavior. This led to a siuation in which we were
running binder incalls to the system process at nice=10 but cgroup=fg.

That's fine as far as it goes, except that if a GC happened in the handler
thread, it would be promoted to foreground priority and cgroup both, to avoid
having the GC take forever. Then, when GC finished, the original priority
is reset, and the cgroup set *based on that priority*. This would push the
handler thread into nice=10 cgroup=bg_non_interactive -- which matches the
caller, but is supposed to be impossible in the system process.

The end result of this was that we could be running "lengthy" operations in
the system process in the background. Unfortunately, some of the operations
that wound up like this would hold important global system locks for up to
twenty seconds as a result, making the entire device unresponsive to input
for that period.

This CL fixes the binder incall setup to ensure that within the system process,
a binder incall is always begun from the normal foreground priority as well
as cgroup. In practice now the device still becomes laggy/sluggish when the
offending lock-holding time-consuming incall occurs, but since it still runs
as a foreground task it is able to proceed to completion within a short time
rather than taking 20 seconds.

Fixes bug #2403717

Change-Id: Id046aeabd0e80c48eef94accc37842835eab308d
8c6cedc9bc9a4b69616a79a95449f6f6b08c7bf1 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.
07d69893e1677bd59a3461a0c4fcd3541563144d 08-Nov-2009 Christopher Tate <ctate@android.com> Reset binder service threads' cgroup/priority after command completion

To prevent buggy command implementations from poisoning binder threads'
scheduling class & priority for future command execution, we now reset the
cgroup and thread priority to foreground/normal when a binder service thread
finishes executing the designated command.

Change-Id: Ibc0ab2485751453f6dc96fdb4eb877fd02796e3f
6dfe8f1ffad455363fff4fe69ced6da386970fbc 06-Nov-2009 Evan Millar <emillar@google.com> Revert jparks code from IPCThreadState.
b5c41353337b3db2dc0ca0df163d5294af8281bc 04-Nov-2009 Jason Parks <jparks@google.com> When a thread is about to be put back onto the thread pool ensure that it is in the foreground cgroup.
dcd3958c5086f757dc09472700ae7384efea7fc8 03-Nov-2009 Jason Parks <jparks@google.com> Add a warning when we leave threads in the binder thread pool in the background scheduling group.
d43b194b69fca6c81023effc921fcc7576bad496 17-Jul-2009 Marco Nelissen <marcone@google.com> Instead of using -1 for pid and uid in the simulator, and then having
to special-case the simulator case all over the framework, just use
getuid and getpid, and intercept those in the simulator wrapper.
c5b2c0bf8007562536b822eb060fc54a01f8e08b 20-May-2009 Mathias Agopian <mathias@google.com> move libbinder's header files under includes/binder
208059f67ed2dd9fa025e07fcb6954d3cb61c79e 19-May-2009 Mathias Agopian <mathias@google.com> checkpoint: split libutils into libutils + libbinder