Bug #5525888
Uses only 25% of the original amount of OpenGL API calls
Fillrate usage is now 1x the screen size instead of 5x
Change-Id: Icc7d2793f276fb7ce23c7f652079e54e3d4779d5
We could sometimes allow a process to be killed while still waiting for
an activity in it to finish stopping.
Change-Id: Ibf89665c4ad6da6be22de04a82b19ef778a7fda0
We now generate a stack-trace looking thing at the top of the report.
Also fix a bug I hit where the phone window manager was sending a
broadcast before the boot had completed.
Change-Id: I0cee16180e4d05c9bd3fe715212a28f504ec91ac
Improved quick launch bookmarks to support category-based shortcuts
instead of hardcoding package and class names for all apps.
Added a set of Intent categories for typical applications on the
platform.
Added support for some of the HID application launch usages to
reduce reliance on quick launch for special purpose keys. Some
keyboard vendors have hardcoded launch keys that synthesize
"Search + X" type key combos. The goal is to encourage them
to stop doing this by implementing more of HID.
Bug: 5674723
Change-Id: I79f1147c65a208efc3f67228c9f0fa5cd050c593
* commit '4e5d3f2ca05b513640d3163155756e01ae577d54':
Add the min fps option to set the min fps in the media recorder test. Add the procmem log to the media memory stress test.
You can run tests for exactly N iterations regardless of duration now,
in addition to the previous time-limited behavior.
(Clean cherry-pick to break a dependency on a previous patch that
needs work before being committed.)
Change-Id: I2e6cf511bbe968a6f95391567658722e87dfa1fe
Turning animations back on exposed this. The problem is that when the
screen brightness changes, it initiates a brightness animation. When
we force the screen to black as we wait for it to be ready to display,
it sees that an animation is running so stops it and thinks this means
it should now turn the display off.
To fix this, don't modify the screen brightness while we are waiting
to show the screen. This is good anyway because the whole point is to
avoid showing the screen until ready, and modifying the brightness at
that point would turn it on prematurely.
Change-Id: I84b296f8ca5705c2d237ea7741cdeb95c5521df9
No clients can signal a format change on either audio or video track (or both)
and a time discontinuity (timestamps changed) independantly.
Change-Id: I3e6cf4e7c260e85759879d61a9b517f68431c22f
related-to-bug: 5553055
a) one of the two decoders has a pending discontinuity
b) the renderer holds on to all output buffers for that decoder
c) the renderer is paused
if all three conditions are met the decoder won't ask for more input data
and therefore never see the discontinuity.
To avoid this we briefly resume the renderer just before shutting down.
Change-Id: I9e08af2a1eb4298d1cd00497d6aa33f4ad184e9a
related-to-bug: 5655016
There was an error in some of the OpenGL layer logic such that we would
occasionally set up a layer for rendering and then not clean up when it was
done. This caused future OpenGL rendering to go into that layer instead of
to the buffers being displayed on the screen, resulting in artifacts including
flashes and displaying of stale content. This happened specifically when
using the wifi settings dialog with the InputMethod keyboard displayed,
but it was probably visible in other situations as well.
Issue #5628248: Flickering/flashing after entering password for WiFi
Change-Id: I38139f620b310f4309570fa7224552d2ee633999
