TapGestureDetector callbacks onPress and onTap can be called in wrong order [369648479]

Fixed

Bug

Status Update

No update yet.

Description

je...@google.com

created issue #1

Sep 25, 2024 07:01PM

When the down and the up event arrive in rapid succession, it is possible that the onPress callback is executed after the onTap callback.

It is currently not possible to reproduce this in a test, because we use an UnconfinedTestDispatcher. When we switch to a StandardTestDispatcher, the following test (when added to TapGestureDetectorTest.kt) will fail:

@Test
fun testOrderOfExecution() {
    val events = mutableListOf<String>()
    rule.setContent(
        layoutWithGestureDetector {
            detectTapGestures(
                onPress = { events.add("onPress") },
                onTap = { events.add("onTap") }
            )
        }
    )
    rule.onNodeWithTag(TargetTag).performTouchInput {
        down(center)
        up()
    }
    rule.waitForIdle()
    assert(events.size == 2) { "should have received 2 events, but received $events" }
    assert(events[0] == "onPress") { "first event should be onPress, but events were $events"}
    assert(events[1] == "onTap") { "second event should be onTap, but events were $events"}
}

While very difficult, I think you could reproduce it in a demo app with an incredibly short tap.

Comments

jo...@google.com <jo...@google.com> #2Sep 26, 2024 09:44AM

Reassigned to jo...@google.com.

Hi Xiangjun, do you know what is going on here?

je...@google.com <je...@google.com> #3Sep 26, 2024 01:29PM

Make sure they use the same session ID/VendorID/STATIC STS IV/address on both sides.

Message last modified on Sep 26, 2024 01:31PM

ap...@google.com <ap...@google.com> #4Dec 6, 2024 07:50PM

Marked as fixed.

Hi, can you make sure that the same session Id and session key are used on both sides? https://developer.android.com/reference/kotlin/androidx/core/uwb/RangingParameters?hl=en#sessionId()

pr...@google.com <pr...@google.com> #5Jan 15, 2025 06:30PM

As far as we can tell, we are setting the same values, as Estimote / Qorvo don't actually publish any useful information on how to actually use their UWB beacons / DWM3000EVB running in Nearby mode.

The Bluetooth incoming data is in this format:
// 0x01, 0x01, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Fixed data
// 0x13, // configLen - 15

// 0x01, 0x00, 0x00, 0x00, 0x3f, 0xf5, 0x03, 0x00, 0xb8, // Fixed data
// 0x0b, 0x00, // Preamble - 25
// 0x00, 0x01, 0x09, // Fixed Data
// 0x09, 0x00, // Channel - 30
// 0x01,
// 0x7c, 0xd2, // Dest Addr - 33

So we get the Preamble / Channel / Dest Addr from the Bluetooth data.

The outgoing Bluetooth packet data is in this format:
// Android timings
val packetPayload = byteArrayOf(
0x01, 0x00, 0x00, 0x00, 0x17, 0x45, 0x55, // Fixed data
0x11.toByte(), 0x22.toByte(), 0x00, 0x00, // SessionID - 7
0x0b, // preamble - 11
0x09, // channel - 12
0x06, 0x00, // num slots - 13
0x60, 0x09, // slot duration - 15
0xf0.toByte(), 0x00, // block duration - 17
0x03, Fixed Data
0x11.toByte(), 0x22.toByte(), 0x33.toByte(), 0x44.toByte(), 0x55.toByte(), 0x66.toByte(), // STS IV - 20
0x46, 0x59.toByte(), // SRC_ADDR - 26
)

So we return the session ID and STS IV, although Android also needs the vendor Id which is set to 0x004c.

UWB seems to be the king of proprietary data with no documentation on anything... perhaps if you pay $5000/year to FiRA you get something, but as an application developer just wanting to use UWB ranging this shouldn't be necessary!

Issue 369648479

Description

Issue summary

Comments

jo...@google.com <jo...@google.com> #2Sep 26, 2024 09:44AM

je...@google.com <je...@google.com> #3Sep 26, 2024 01:29PM

ap...@google.com <ap...@google.com> #4Dec 6, 2024 07:50PM

pr...@google.com <pr...@google.com> #5Jan 15, 2025 06:30PM

Add comment

Issue metadata