The isGrayscale family of methods is designed to identify
drawables and bitmaps that apps are using in the largeIcon
position to pose as small icons in order to get the
appropriate background treatment (a solid blue or gray block
in KK/JB, or geniune selvedge denim in ICS/HC).
We can optimize this search two ways:
(1) Reject immediately any largeIcon that is larger than
largeIcons should be (64x64dp). We could one day simply
reject, or resize, these in the notification manager,
but regardless these are not plausible smallIcon
subsitutes. This new constraint is commemorated in the
new name, isGrayscaleIcon().
(2) Shrink the bitmap even smaller before scanning it slowly
in Java. This lets native_drawBitmap do the heavy
lifting across the entire bitmap; we need only scan a
few pixels.
Bug: 16513124
Change-Id: I3a2b79130ed2465a4aedfbb5a556db7f8a7aa132
...around writing settings. It does its own proper permission check;
it just needs to make sure not to accidentally crash the caller in
strange and wondrous ways because of failing to clear binder identity
before writing the result to secure settings.
Bug 16542048
Change-Id: I88d1f2dbeebd24eed5d86989f0ca0d834878b054
Move MMS api to using content provider rather than byte[] to pass MMS message contents.
Rebased and merged into TOT.
Change-Id: I3509b2774b1cb30a1c8100bb25d283140c963b6b
Using compression and decompression for moving bitmap data
acorss processes is slow as compression is expensive. This
change switches to using direct streaming of the bitmap
data.
bug:15938254
Change-Id: I78bc450031ee60ada4c3b66f14586a73c72ce34f
1. Fixed a crash when orientation changes and the content
is scrolled due to wrong size bitmap being requested.
2. Closed a file dscriptior that was being left open.
3. Clearing the bitmap before passing it to the renderer to
ensure it is white for pixels not touched when rendering.
4. Removed debug logs.
5. Switched to the correct layout manager for RecyclerView.
bug:16966145
Change-Id: I8ab9d22635c93cac5ff85c6f4b5d82e58cd8df5c
Fix intelliJ warnings in ResourceHelper. Most of them just change
boolean checks "x == false" with "!x".
Change-Id: I278645e2807affd8b3183a4a6f5e4fa2ab7b3d21
Bug: 17208461
There's a potential race condition between HardwareRenderer.destroy()
being called (which calls destroyCanvasAndSurface()) and the renderer
being finalized (which is what calls freePrefetchedLayers), during which
time it's possible we get a TRIM_MEMORY_COMPLETE and destroy the EGL
context.
Fix this race condition by moving stopDrawing() and freePrefetchedLayers()
into destroyCanvasAndSurface() where they should have been in the first
place.
Also, if we hit the assertion failure, dump the current state of
Caches to try and provide more context for the failure.
Change-Id: Ife0ba3562041e8b08e87e3e13640472b3004eed6
