We've gotten feedback that the VelocityTracker change was disruptive, though it did not break any of the flutter framework or customer tests. In order to make the change non-breaking, PointerDeviceKind parameter can be made optional.
Nevertheless, this parameter should be provided so that the existing touch handlers can use more accurate gestures on mouse/stylus inputs, so we can encourage this by deprecating the default constructor and pointing users towards the VelocityTracker.withKind constructor that takes a non-optional parameter
PR #65873 enabled DDS for non-web Flutter applications. This change
surfaced a bug where DDS would not send ServiceRegistered events to VM
service clients when they subscribed to the Service stream. This would
cause tools and tests that rely on these events (e.g., hot reload in
VSCode) to fail.
Fixes#66038.
This reverts commit 66b01c1f2905f6b4f845f7283abe3e458351fe2e.
* Add DDS ipv6 support
* Use --dds-port for DDS instead of hijacking --host-vmservice-port
This fixes a problem where the character field of the RawKeyEvent was not being set at all for non-Android platforms.
I also updated the key maps, and corrected a problem with the Windows key map where the backquote character wasn't correctly mapped.
Port the deprecated settings devicelab test to tool integration shard. Tests that apps can be built using the deprecated android/settings.gradle file.
Part of #65790
Currently these tests are taking CI time without providing any value, because there is no verification that network connectivity is avoided. This is better covered by a unit test that verifies that --offline is passed to pub.
Currently the framework uses fairly large "hit slop" values to disambiguate taps from drags/pans. This makes sense on touch devices where the interaction is not very precise, on mice however it can feel as if the UI is lagging. This is immediately noticeable on our infra dashboard, where it takes almost half of a grid square of drag before the actual drag kicks in.
One potential solution is to always use smaller constants depending on whether the interaction is mouse or touch based. The only reasonable choice is to use the pointer device kind and not target platform - same platform can have different input sources. This requires exposing the pointer device kind in a few new places in several of the gesture detectors, and using the enum to compute the correct hit slop from an expanded set of constants.
This almost works, however there are a few places (notably ListViews) which uses the touch hit slop as a default value in scroll physics. It does not seem like it will be easy to disambiguate a user provided scroll physics constant from the default and/or adjust it somehow - this might require significant changes to scroll physics which I have left out of this PR.
This PR does not adjust:
kTouchSlop used in scroll_physics.dart's minFlingDistance
kTouchSlop used in PrimaryPointerGestureRecognizer/LongPressGestureRecognizer
Previously, the CPU/GPU measurement using gauge happened after the
driver test is done. Now, the measurement happens within the driver
test. So we need to properly increase the delay and duration to get a
comparable reading as the old gauge measurements.
