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 desc.txt file can now mark parts as 'must finish cleanly' by using
'c' as the part line prefix rather than 'p'. If so indicated, if the
bootanimation is asked to quit it will do so only after waiting to
finish that part.
I considered either making init.c service killing smarter or promoting
bootanim to be a bindable service with a requestExit method. However,
these changes are probably too big/risky given our ship date. So
I used a property as a mailbox between SurfaceFlinger and bootanim.
Bug: 6679877
Change-Id: Id7dca22caa50b450fff25ca94f7242d971034f41
When turning the screen off we could have 2 waiters on the
vsync condition: The main vsync waiter as well as one in
onScreenReleased(). We were only signaling the condition though,
so it it would be possible to wake onScreenReleased() without waking
the main vsync thread which would then be stuck in .wait().
We fix this by just using broadcast() when receiving a vsync event.
We also add a broadcast() to signal when the state of
mUseSoftwareVSync changes. This is important particularly for
the transition from hardware to software vsync because the main
vsync waiter might have observed mUseSoftwareVSync == false
and decided to block indefinitely pending a hardware vsync
signal that will never arrive.
Removed a potentially deadlocking wait for a signal in
onScreenReleased(). The function was trying to wait for the last
vsync event from the hardware to be delivered to clients but there
was no guarantee that another thread would signal it to wake up
again afterwards. (As far as I can tell, the only other other
thread that might wake it up at this point would be a client
application issuing a vsync request.) We don't really need to wait
here anyhow. It's enough to set the mUseSoftwareVSync flag,
wake up the thread loop and go. If there was a pending vsync
timestamp from the hardware, then the thread loop will grab
it and use it then start software vsync on the next iteration.
Bug: 6672102
Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
When turning the screen off we could have 2 waiters on the
vsync condition: The main vsync waiter as well as one in
onScreenReleased(). We were only signaling the condition though,
so it it would be possible to wake onScreenReleased() without waking
the main vsync thread which would then be stuck in .wait().
We fix this by just using broadcast() when receiving a vsync event.
We also add a broadcast() to signal when the state of
mUseSoftwareVSync changes. This is important particularly for
the transition from hardware to software vsync because the main
vsync waiter might have observed mUseSoftwareVSync == false
and decided to block indefinitely pending a hardware vsync
signal that will never arrive.
Removed a potentially deadlocking wait for a signal in
onScreenReleased(). The function was trying to wait for the last
vsync event from the hardware to be delivered to clients but there
was no guarantee that another thread would signal it to wake up
again afterwards. (As far as I can tell, the only other other
thread that might wake it up at this point would be a client
application issuing a vsync request.) We don't really need to wait
here anyhow. It's enough to set the mUseSoftwareVSync flag,
wake up the thread loop and go. If there was a pending vsync
timestamp from the hardware, then the thread loop will grab
it and use it then start software vsync on the next iteration.
Bug: 6672102
Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
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
this would happen when a resize was pending (ie: we have received
and processed a resize transaction but have not received a buffer
with the right size) and a new transaction came in that didn't
involve a resize, for instance a translate-only transaction.
in this case, we would incorrectly update the drawing state
with the pending size, eventhough we still don't have a buffer
for it.
the solution is quite simple, we never allow the size to propagate
from current to drawing state during the regular transaction processing
(unless we are in fixed-size mode -- meaning we don't need to have
a matching size buffer), this propagation happens later once we
receive the buffer.
Bug: 6624163
Change-Id: I11a97e4b88a7f3a0571ddcfe99c86cb04ce01a4d
this allows us to enable h/w acceleration on low-end
devices while keeping memory usage down.
Bug: 6557760
Change-Id: I8af2de3038dc2579360b8b73aa452cb7a0e506a9
This is for a 7in hdpi/tvdpi tablet with 1G of RAM.
That sounds kind-of familiar. I don't know. Have I seen
such a thing before? Maybe.
Bug: 6576049
Change-Id: Iabc245692d5106feec9199eb2b5a3d06e27a9b83
this would happen when a window started with size A, was
resized to B and immediately resized to A. In this situation
the erquested and active size would be the same, and SF
would think a transaction wasn't needed.
we fix this by always comparing the requested sizes.
Also, make sure to set mRefreshPending once we're sure
we have succesfully called updateTexImage().
Bug: 6580962
Change-Id: I2c48b4df7f05fd35c9e1d2dd82095b0f3d5a0b6a
