use gui/DisplayEvent to receive the events. Events are
dispatched through a unix pipe, so the API is compatible
with utils/Looper. see gui/DisplayEvent.h for more info.
Bug: 1475048
Change-Id: Ia720f64d1b950328b47b22c6a86042e481d35f09
Revert "Add support for sending VSYNC events to the framework"
This reverts commit f3918c5bd4bc9f02f74da42995564150ca2dd382.
Change-Id: I998e3e1aa3fa310829ae973b64fe11b01f6f468f
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
Perform uniform argument escaping inside NativeDaemonConnector, using
varargs to separate boundaries. Also move to parsed NativeDaemonEvent
instances instead of raw Strings.
Bug: 5472606
Change-Id: I1270733e2b2eeb2f6b810240df82ab24d38ebf40
* changes:
Add support for sending VSYNC events to the framework
BitTube::read now handles EAGAIN
split ComposerService out of SurfaceComposerClient.h
rewrite SF's message loop on top of Looper
use gui/DisplayEvent to receive the events. Events are
dispatched through a unix pipe, so the API is compatible
with utils/Looper. see gui/DisplayEvent.h for more info.
Bug: 1475048
Change-Id: If4126023fc9c067e56087ec7d16a8fd542ce1794
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
Make surface management between SurfaceView and the window manager
much more controlled, to ensure that SurfaceView always gets to report
the current surface is destroyed before the window manager actually
destroys it.
Also a small tweak to allow windows that have a wallpaper background
to still have a preview window. This makes launching home after it
has been killed feel much more responsive.
Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
Secondary nets sometimes come up with no routes, but parsing errors end up with null
routes getting added. Trim that away. Also added some dumpstate logging of the secondary
route tables and rules.
bug:5615697
Change-Id: I94c9d888bab958df44891b9117236436e046cc7f
Progressively reduce the sleep time applied in MixerThread::threadLoop()
in case of consecutive application underruns to avoid starving the audio HAL.
As the default sleep time is longer than the duration of an audio buffer
we ended up writing less data than needed by the audio HAL if
the condition persisted.
Issue 5553055.
Change-Id: I2b23ee79c032efa945025db228beaecd1e07a2e5
EntropyService implies that this program provides entropy to other
programs, and is misleading. The EntropyMixer class is designed purely
to stir the existing entropy pool with some possibily random-ish data,
and carryover entropy across device reboots.
Change-Id: I086cd339a3b652d32371521e61e1b1f555ce2280
PIE did not work together with inlining. This change combines (almost
all of) the performance benefits of ARM optimizations together with PIE.
Change-Id: I4594d33ae5a0a7bac327ae08e30fb35343a06256
Move NTP updates outside locks to avoid blocking ShutdownThread. Add
logging around trim events that remove substantial history. Include
history start in sample events.
Bug: 5627247, 5584564
Change-Id: If9bbd93842c710efcdec94e68da87e9e42a5f961
...through setup wizard after wipe data
Deal with finish() being called when there are no running activities
on the stack.
Also some improved debugging output.
Change-Id: Ia1d3f3f7e7b79c06ca95c738081322fc80282e0d
When a device is attached to a desk dock, the
CATEGORY_DESK_DOCK intent will no longer be fired.
As a side effect, the "dock home" behavior (which captures
the home key for the dock app as long as the device is
docked) is now disabled for desk docks.
Car docks are unchanged.
Bug: 5591015
Change-Id: I7884f655913c31cf53b88cb2e2b371987be27f64
