In /proc/pid/maps the main stack is identified as "[stack]". In Linux 3.4
thread stacks are identified as "[stack:<tid>]" where <tid> is the thread ID of
the thread using that stack. Add support in MemInfo's otherStats to track
memory being used by the stack.
Add sanity check on the length of the otherStats array.
Add detail messages to two null pointer exceptions.
Bug: 8265251
Change-Id: I2b228b147da9bdc5c7a4d825dfc628fcc7923927
Currently when malloc uses a page rather than brk the heap gets accounted as
ashmem memory. Previously the memory would be accounted as unknown but since
[1] it gets accounted as ashmem. This change makes the accounting see this
memory as being native, ie the same kind of memory we associate with brk.
[1] https://android-review.googlesource.com/#/c/49583/3
Change-Id: I6f496cfeb590268d41d8e047b12cd5c90359e2b0
Display events in each batch received from IPC were being processed in
reverse order, and stopped after the first vsync event (latest
chronologically) was handled. This makes perfect sense for vsync
events, but is broken for hotplug events.
Now we process them all in order, handling all except vsync as we see
them. For vsync events, only the last is reported.
Bug: 7491120
Change-Id: I448d139d21dc27128d75ca1d661de666fff51bcb
"startPos + addedRows < requiredPos" could miss a row in boundary position.
Because of the fluctuating row size, "startPos + addedRows < requiredPos" expression could miss a row in boundary position.
For example, simply speaking,
if window capacity = 120 and requiredPos = 120,
"fillWindow" needs to be newly called and "starPos" is 80 for the window.
Unfortunately 120th row is bigger than the rest size of the window,
the row for requiredPos is not in the window.
Then, startPos has to be newly set and the 120th row has to be included in the window.
But by the expression above "startPos + addedRows < requiredPos",
the row for requiredPos is regarded as included in the window.
In that case, by "mCurrentRowID = Long.valueOf(getLong(mRowIdColumnIndex));" statment in AbstractCursor,
IllegalStateException is thrown.
This patch contains modification of the expression as "startPos + addedRows <= requiredPos".
Change-Id: Iaee75241e495949b0a624b836843da18d0bcb98d
jchars is not released correctly if factory is NULL.
In addition, unnecessary string conversion removed.
Change-Id: I3ea58391dfe7a96ea6d6ae61bb0867a2d8d49fb0
A change in the VM triggers a native memory error more aggressively than before,
showing that there's a bug in the logic of recycling bitmaps. Since the pixel
memory is allocated on the Java heap, nulling out the reference to that memory
in the Java level Bitmap object can cause that memory to get collected at any time.
Meanwhile, we may have a reference to that memory at the native level for rendering
purposes, causing an error if/when we access that memory after it has been collected
by the VM.
The fix is to avoid setting the reference to the pixels to null unless we are
not referring to it in native code. This is determined at the time we call
recycle() - we return a boolean to indicate whether the native code is still
using the memory. if not, the Java code can null out the reference and allow the
VM to collect it. Otherwise, it will get collected later when the encompassing
Bitmap object is collected.
Issue #7339156 HTML5 tests crash the app (Vellamo)
Change-Id: I3a0d6b9a6c5dd3b86cc2b0ff7719007e774b5e3c
This change makes use of the new 'secure' argument to the
ISurfaceComposer::createDisplay method. In this change both the overlay and
wifi displays are hard-coded to be non-secure displays.
Bug: 7368436
Change-Id: Ib65312f2adab5104d8deefbfc32af9dc106a9129
Bug #7353771
This API can be used when scaling large images down to a small size
to get nicer looking results.
Change-Id: If09087eed36077eee5355f6047a3ca67747d7d9e
This change makes WindowManager use the new eAnimation flag when animating
windows. This prevents some of the window updates from being combined with
updates from prior animation frames.
Bug: 7353840
Change-Id: I5a9f8fa2c1a2f5f08363a45cd9f28bb97cd77080
