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
SurfaceFlinger will no longer directly synchronize with early suspend.
Instead, PowerManagerService will synchronize with SurfaceFlinger to
ensure that a black frame has been drawn on the display, and then
trigger all early suspend handlers.
Change-Id: I07acdd628440d23fdb69db94319ec5d65d3f4919
When "adb bugreport" was run on previous adb releases, it
called "adb shell dumpstate". In later versions of Android,
this was changed to "adb shell bugreport", which starts
the dumpstate service.
Modify the dumpstate command so that it calls bugreport
when it's not running as root. This allows both
"adb shell dumpstate" and "adb shell bugreport" to have
the exact same output.
Bug: 6391938
Change-Id: Ia32bb9ebc579db3bee7caa0fe66dc3f124d60a12
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
this bug introduced recently would happen when the very first
buffer of a surface was rejected for not having the right size
Bug: 6577035
Change-Id: I9fabf20006019f2a6c308be7c7f5c05bdcfd5014
