Sometimes dumping threads takes a long time and bugreport times
out. This change will cause us to accept the bugreport socket connection
before dumping threads and should avoid the failed to connect to dumpstate
service problems we've seen.
Bug: 17758374
Change-Id: I80afa0353cf1c340873f481a8d1d7faffff54120
We normally recompute layer visibility when a layer gets its first
buffer; before then it's treated as invisible. Sideband layers never
get a buffer (as far as SurfaceFlinger knows), so never became
visible. Now we also recompute visibility when a layer gets a new
sideband stream.
Bug: 17752511
Change-Id: I84e150f196eb2eb7bcd2616248e5e3fa73624809
Try to clean up the code paths coming in and out of binder IPCs to
plug any places where we could disrupt the gather flag of a thread,
causing it to keep gathering stack crawls (which is the thing that
is causing our strict mode data to become so large).
We now take care of saving and restoring this state in the core
IPC code path, not at the Java layer.
Change-Id: I73d564778da127bdce00f304225930e7f2318293
When HWC doesn't provide DPI values for a display, we pick a default
DPI based on resolution. The intent was that 1080p and higher displays
would get XHIGH density, and lower resolutions would get TV density.
In KK (and possibly forever) we had a bug that we'd always use TV
density. That was fixed in L, but that fix exposed a pre-existing bug
that we always used the display's height in its native orientation,
rather than in landscape orientation. So an 800x1280 tablet like N7v1
started getting XHIGH density instead of the intended TV density.
Bug: 17461633
Change-Id: Ia57fa49e61f36bdda63ce283ef62c9953297222c
If the destructor of SensorEventConnection gets called when the main
sendEvents loop of SensorService is executing it may result in a deadlock.
The loop promotes each connection to a strong_pointer, calls sendEvents
and cleans up the connection if necessary. It is possible that the sp's
destructor may delete SensorEventConnection which will call the dtor
~SensorEventConnection(). This dtor again needs SensorService mLock to
execute which may result in a deadlock.
Bug: 17617897
Change-Id: I76c244dbe85fadb591c0bd1a9a5eb01d93f56505
This is used by media service to schedule video frames at the
proper time, based on precise vsync timings.
Bug: 14659809
Change-Id: I1a90603f3dc09dca9aa4f90a3aa845fab56e0a5e
i) Initialize sensor_event.flags to zero or wake_up flag before sending dropped flush_complete_events. This will avoid unnecessary acks.
Currently it is not set to anything which may result in garbage values for flags field.
ii) Change the dump format of SensorEventConnection.
iii) Add const to method signatures wherever applicable.
Bug id: https://b2.corp.google.com/issues/17498626
Change-Id: Ia736ffb01c366540aab73cdcf596ce852c052593
Previously, the vibration was not performed until after stacks
were gathered which takes a long time. Moved the vibration
to happen earlier so we provide better user feedback for the
three-button salute when collecting a bug report.
Deleted some dead code for playing begin/end sounds.
Improved the timing measurement code to help track down why
bug reports are so slow. (They take over a minute now which
can cause us to lose valuable diagnostic information.)
Bug: 17474152
Change-Id: Iac73f7993d7dc85196aad96f459b22fd4a710f94
i) Significant Motion multiple clients fix. Make a copy of
mActiveConnections vector before cleaning up SensorEventConnections
when one-shot sensors trigger.
ii) Maintain a mapping between flush_complete_events and
SensorEventConnections to accurately map flush() API calls and
corresponding flush_complete_events
iii) Remove all references to 1_1 and 1_2 HALs.
iv) Dynamically allocate sensor_event buffers in SensorService main
threadLoop.
Bug: 17412359
Change-Id: If3c3986197660cafef2d2e0b4dc7582e229cf1c4
Lajos Molnar