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
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
As part of scheduling policy cleanup, remove or isolate
all references to the scheduling policy APIs.
Change-Id: Ia1ea2fe711a399039f25217309e061267744b856
prctl(PR_SET_NAME) limits to 15 characters. Before we had names like
"Binder Thread #" and the counter was cut off :-( Also remove redundant
"thread" at end of name; it's always a thread.
Change-Id: I1f99c2730ba0787ed9b59c15914356cddf698e2f
MemoryHeapPmem is not used any longer. PMEM is not a supported
type of memory by the system anymore. a particular device might
use PMEM and need something like MemoryHeapPmem, in this case this
should be implemented in device specific code (HAL).
This will most likely break older no longer supported targets.
Change-Id: I434e4291219950018de8b793b0403bb2d92dd5cc
Services now must explicitly opt in to being accessed by isolated
processes. Currently only the activity manager and surface flinger
allow this. Activity manager is needed so that we can actually
bring up the process; SurfaceFlinger is needed to be able to get the
display information for creating the Configuration. The SurfaceFlinger
should be safe because the app doesn't have access to the window
manager so can't actually get a surface to do anything with.
The activity manager now protects most of its entry points against
isolated processes.
Change-Id: I0dad8cb2c873575c4c7659c3c2a7eda8e98f46b0
