File changed.
Preview size limit exceeded, changes collapsed.
File changed.
Preview size limit exceeded, changes collapsed.
File changed.
Preview size limit exceeded, changes collapsed.
Loading
Allow multi-window multiple device streams
Before this CL, only one device could be active in the system at a given time. This was enforced early inside the dispatcher code. In this CL, this restriction is removed, and a new restriction is introduced: - At most one input device can be active for a given connection That means that it's now possible to touch one window and draw with stylus in another. This is implemented by moving the "changed device" check from the TouchState into InputState. This should work OK because there will be a unique ViewRootImpl per connection, and the UI toolkit will continue to process the events in a single-device mode. In the future, we can consider enabling same-window multi-device streams. This would likely require a new public API. After this CL, the dispatcher will work in the following manner: TouchState -> always works in the multi-device mode. Assumes 1 window can receive multiple pointers from different devices. InputState (per-connection) -> acts as a rejector / multiplexor. It only selects a single device to be active for the given connection. This is done so that in the future, we can potentially turn off the "single device active" behaviour of InputState without having to change other parts of the dispatcher. What happens if there are multiple device streams being sent? - In general, latest device always wins - Exception: stylus always takes precedence over other devices - Latest stylus device cancels the current stylus device One other behaviour there: - If for the same device id, source changed (this is one of the tests), then the current gesture is canceled. Additional changes: The case of touch pointer down -> mouse down -> second touch pointer down does not cancel mouse. For simplicity, we just wait for a new touch gesture to start before canceling the current mouse gesture. Pilfer pointers changes: Previously, two devices being active in one window cause pilferPointers to fail. The new behaviour is that all of the active gestures in the spy window that's doing the pilfering are going to get pilfered. So if a spy window is receiving mouse and touch, then both mouse and touch gestures are going to be pilfered (because the windows below the spy would be getting independent mouse and touch streams). In practice, in this CL the spy will never receive two devices at the same time, because we are only allowing single device to be active per-window. But the understanding here is that eventually, we may want to have multiple devices going to the spy. How same-token windows are handled: During TouchState computation, the windows with the same token are treated separately (since they do have a different layer id). Then later, during TouchState -> InputTarget conversion, they are all lumped into one target. One problem with this approach is that sometimes, we want to generate HOVER_EXIT with response to receiving ACTION_DOWN event. This is because InputReader today doesn't always generate HOVER_EXIT prior to sending ACTION_DOWN. That means that the dispatcher has to have a special logic for dealing with these cases. The approach taken in this CL is to force-generate new DISPATCH_AS_HOVER_EXIT input targets, which would allow them to remain separate from DISPATCH_AS_IS input targets for the ACTION_DOWN event. This avoid the collision of pointers. Otherwise, we would add a pointer id for the HOVER_EXIT event, which would not be valid for the ACTION_DOWN event's pointer id. Bug: 211379801 Test: TEST=inputflinger_tests; m $TEST && $ANDROID_HOST_OUT/nativetest64/$TEST/$TEST Change-Id: If2eae87bc2a40b61144ddcd019a9800c2d526072