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
* commit '60fa4617bc4be292a9e0ae10cf259153dec07aa9':
Don't enable input dispatch until the screen is visible.
Dejank electron beam.
Don't process UEvents in Dalvik unless they match a pattern.
On some devices, vsync is delivered from the kernel to userspace
over a netlink socket via UEvent. The result is that a thread wakes
up, reads a message, creates a new String then searches it for matches
against a pattern on every single frame.
Reduce the overhead by performing the initial pattern matching in
native code.
Bug: 7326329
Change-Id: Icb22db1c38330694207bec1153840e0c06f502d6
Add support for querying AudioManager to know whether speech
recognition is currently underway.
Don't play a notification if speech recognition is underway.
Bug 7314859
Change-Id: I1bd013a3168cfe1a6b6dcfd28565e1c3c512eb6a
The AudioService now tracks the shutter sound enforcement status, in
addition to the existing approach. Check with it when doing shutter
sound operations.
Bug: 7032634
Change-Id: Ief855d3a36ca5679832cf439f5638b10f70b8636
The failures were caused by the implementation of doTextRunCursor
passing a too-small value for contextCount into the underlying
getTextRunAdvances call (it wasn't accounting for the start offset).
Thus, when getTextRunAdvances made a copy of the text for its cache key,
it was getting a partial copy.
This patch fixes the size so the cache key always has a full copy of the
text.
Change-Id: I57e3ac6de7aef0e1f1c7000dc3d653f9b0d623d2
This fixes bug 6948776
android.graphics.cts.PaintFlagsDrawFilterTest#testPaintFlagsDrawFilter
failures on JO
When we moved the drawing of text decorations (underline, strikethrough)
from Skia to our own drawing (so we could take into account the metrics
computed by TextLayoutEngine), we just used the raw flags from the
paint, which ignored the overrides that a DrawFilter can effect.
The patch simply checks for the existence of a DrawFilter in the canvas,
and applies it to a copy of the paint where present. This will be one
extra paint copy where the filter exists, but that's expected to be rare
(other than running this CTS test, of course).
Change-Id: I664c478b73a3a1cc43599ee11bbc02c69b7a96c2
This bug was triggered by user code concurrently mutating the character
array while calling into a drawText method in another thread. When the
value of the array changed, it caused inconsistent state, leading to
assert failures.
This is arguably bad behavior by the user code, but it shouldn't cause a
native crash. The fix is to do a defensive copy of the text into the
key, so the value is guaranteed to remain constant throughout the text
layout process. The change is mostly deletion of code, because there was
an optimization to try to avoid such a copy. That optimization was not
actually effective, however, because the indexOfKey() operation in the
KeyedVector underlying the TextLayoutCache did the copy anyway. Thus,
even though this change looks like it's introducing a copy where there
wasn't one before, the actual performance impact should be nil.
Note that the ability to handle a mutating argument is now part of the
contract for TextLayoutEngine::getValue(), and is now documented. That
contract may change, as the result of future optimization. Also, care
was taken to only use the value after the copy.
Other performance issues with TextLayoutCache are tracked in bug
7271109.
Change-Id: I9c90e8e4d501f3f37e2f22a7851f032808d46fbe
Copy and paste error where wrong compare meant the code thought a target
utilization option was specified even if there wasn't one.
b/7062303
Change-Id: Ibf1c6cf72743c5fbec7618a719d12d0373184754
Copy and paste error where wrong compare meant the code thought a target
utilization option was specified even if there wasn't one.
b/7062303
Change-Id: Ibf1c6cf72743c5fbec7618a719d12d0373184754
When memory gets low on a device, activities flush everything they can.
Hardware-accelerated activites, such as Launcher, flush GL resources and destroy
the GL context. However, some resources were still hanging around, due to deferred
destruction policies (we don't delete layers until the DisplayLists they are in
are finalized, to ensure we don't deref deleted objects). This meant that we were
referring to obsolete GL data in these objects. in particular, it meant that we might
come around later, after a new GL context was created, and delete a texture object
that was incorrect. We use the layer's "texture id" to refer to the texture underlying the
layer. But if there's a new GL context, then this texture ID is no longer valid, and
we may be deleting the texture that a different object (layer, icon, whatever) is referring
to, because the driver may return that same ID under the new GL context.
The fix is to more aggressively delete things that we know will not be used again
when the GL context is destroyed. In particular, we delete all resources being used
by all DisplayLists at GL context destruction time.
Issue #7195815 Textures corruption on all devices, in many apps
Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
