Fallout from the Flattenable change, update all its uses.
Additionnaly, fix/tighten size checks when (un)flatten()ing
things.
Removed the assumption by some flattenables (e.g.: Fence)
that the size passed to them would be exact (it can
and will be larger in some cases)
The code in Parcel is a bit complicated so that we don't
have to expose the full implementation (and also to
keep the code smallish).
Change-Id: I0bf1c8aca2a3128491b4f45510bc46667e566dde
This is currently safe to do only for processes that disallow any binder
threads to be created: setThreadPoolMaxThreadCount(0).
Change-Id: I8a27f3cf26f4d51edb7f222af487ac256cbcab65
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
- added a ctor that updates and dumps the stack immediately
- added a "logtag" parameter to dump()
Change-Id: Ie51c256071d282591752243bdb4f68cf9ff8829d
Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: Ie7c86f45fa39cb53539cab0ffe8585a585656714
Third-party libraries are currently trying to use the
MemoryBase constructor but failing because we fixed the
definition of ssize_t. This is a stop-gap for users of
this private API until we can get them fixed.
Bug: 8253769
Change-Id: I8a19770f3252d88ee87023fde625cc6289924b0d
When a binder service's main thread joins the thread pool
it retains its name (whatever the exec name was), which is
very confusing in systrace.
we now rename that thread just like its friends in the
thread pool.
Change-Id: Ibb3b6ff07304b247cfc6fb1694e72350c579513e
This is to help implementation of bug #8181262 and maybe
bug #8181261
Note the current code has not yet been tested; it is only
known to compile at this point.
Change-Id: I489674c96d0d3fc0ddacc92611931a19a9ee5230
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
app_main.c).
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
IPCThreadState::talkWithDriver.
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
The Java implementation of writing the RPC response header
calculates the length of the header including the 4 bytes
specifying the header length but the native implementation
excludes the 4 bytes specifying the length from the header
length.
The native implementation has been aligned to the Java impl.
Change-Id: I325bf272a63152d8fded4cf4e51a906b5a9bfe19
Every IBinder object can accept a new transaction to tell it that
it might want to reload system properties, and in the process
anyone can register a callback to be executed when this happens.
Use this to reload the trace property.
This is very much ONLY for debugging.
Change-Id: I55c67c46f8f3fa9073bef0dfaab4577ed1d47eb4
