To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
This change enables the input dispatcher to send multiple touch
events to an application without waiting for them to be acknowledged.
Essentially this is a variation on the old streaming optimization
but it is much more comprehensive. Event dispatch will stall as
soon as 0.5sec of unacknowledged events are accumulated or a
focused event (such as a key event) needs to be delivered.
Streaming input events makes a tremendous difference in application
performance. The next step will be to enable batching of input
events on the client side once again.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I025df90c06165d719fcca7f63eed322a5cce4a78
Since we will not longer be modifying events in place, we don't need
to use an ashmem region for input. Simplified the code to instead
use a socket of type SOCK_SEQPACKET.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I05909075ed8b61b93900913e44c6db84857340d8
* changes:
EthernetDataTracker: Don't run DHCP or set network available until link is up
Only send master volume or mute updates if the settings have changed
Make AudioManager.adjustMasterVolume public and hidden
Allow disabling network stats support in a resource overlay
Restore persisted master volume if the media server restarts
Don't allow changing master volume when muted
Show the flags in package manager debugging.
Modified the constructor of EndpointBase
Add a getEndpointInfo accessor to AIDL-generated RPC proxy classes
Defer persisting master data to avoid excessive database writes
Add an option that disables the AUDIO_BECOMING_NOISY intent send when a headset is hotplugged.
Remove reference counting and client death notification for master mute
AudioService: Send broadcasts when master volume and mute state change
Use the new get/putFlattenable methods on RpcData.
Don't try to unmarshal void return types when there are out parameters being returned.
AudioManager: Add wrapper methods for master volume support
AudioManager: Add support for master mute
NetworkTimeUpdateService: Schedule NTP on ethernet connect as well as wifi
For events, require that the parameters be marked in.
PhoneWindowManager: stifle warning that ITelephony service does not exist
AudioManager: transparently convert volume settings for other streams to master volume if config_useMasterVolume is set.
Support putting Flattenables in Lists.
Was generating code that uses the wrong RpcData.
store the hw addr in the extraInfo field of ethernet NetworkInfos
