Added basic double-tap, based off view click by cleverchuk. Addresses #1642 and #1576 by DavidGrath · Pull Request #1681 · open-telemetry/opentelemetry-android

DavidGrath · 2026-04-09T20:39:39Z

The core difference between this and the original View Click is the use of a GestureDetector instead of relying on MotionEvent directly. As brought up in my comments on the issue, I'd like to know if it's desirable to add configurations to selectively track the double-tap event per-view via some form of allowlist. Then there's the issue of interplay between this and the original view.click

linux-foundation-easycla · 2026-04-09T20:39:47Z

The committers listed above are authorized under a signed CLA.

✅ login: DavidGrath / name: DavidGrath (7c2d59c, 3b43281, 75c1407, 7c58c18, 838d198, a051d4a, ae74e2a, fc26fa0)
✅ login: fractalwrench / name: Jamie Lynch (7c2d59c)

DavidGrath · 2026-04-09T21:13:49Z

Okay, the steps I took before opening this PR include running spotlessApply and testDebugUnitTest successfully. After fixing the missing proguard file and detekt errors, please I'd like to know if there's anything else I would need to do to ensure a successful set of checks

DavidGrath · 2026-04-10T05:59:38Z

I'll make the relevant fixes and revert within 48 hours

codecov · 2026-04-11T04:43:16Z

Codecov Report

❌ Patch coverage is 77.19298% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.31%. Comparing base (7168bd3) to head (75c1407).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...d/instrumentation/view/click/internal/ViewUtils.kt	38.46%	6 Missing and 2 partials ⚠️
...trumentation/view/click/ViewClickEventGenerator.kt	88.63%	0 Missing and 5 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1681      +/-   ##
==========================================
+ Coverage   62.09%   62.31%   +0.21%     
==========================================
  Files         159      160       +1     
  Lines        3411     3460      +49     
  Branches      345      355      +10     
==========================================
+ Hits         2118     2156      +38     
- Misses       1199     1205       +6     
- Partials       94       99       +5

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

thompson-tomo · 2026-04-11T11:33:01Z

+internal const val APP_SCREEN_DOUBLE_TAP_EVENT_NAME = "app.screen.doubletap"
+internal const val VIEW_DOUBLE_TAP_EVENT_NAME = "app.widget.doubletap"


Could we not use a generic click/tap event name and use attribute to ie distinguish between the type ie single/double click

Thanks for the review.

The idea is to eventually expand to other gestures including scroll and pinch, that's the reasoning behind me leaving single tap distinct from double tap

I have no problem with scroll & pinch having dedicated name as they would also have different attributes. However in the case of clicks (single vs double) they would have the same attributes and the number of definitions triples when you consider that it could also be a left vs right click when using a mouse.

Okay, I see it working out like this:

Add the first source and class from InputDevice.getSources() source as 2 attributes

Add MotionEvent.getToolType() as an attribute

Add MotionEvent.getButtonState() as an attribute if it's greater than 0

Merge what I've done so far into the original view click and delete the new double tap folder

I'd be translating the returned integers into strings

What do you think?

Oh, and also add click.type for either single or double

I like that as otherwise we would have had so many different event names.

The question is attribute names. I am thinking:

hw.pointer.type for the tool type as it is describing the hardware that was used

hw.pointer.button for the button state with stylus_primary shortened to primary etc.

hw.pointer.clicks for how many clicks ie 1 or 2

Okay, I assume we're only focusing on SOURCE_CLASS_POINTER since that's where gestures typically come from. I think it's good, although I'd prefer hardware in full instead of shortened.

I'll try and get back to this on or before the 18th

No worries, note hw.* is a defined namespace in semconv. 😉

Ah. Thanks for pointing that out. Noted

…double tap both now rely on `GestureDetector`

DavidGrath · 2026-04-18T13:31:56Z

Main points of discussion:

If the button state isn't primary, then should the event still be sent or actively suppressed?
I've changed the original code to indirectly rely on ViewConfiguration.getDoubleTapTimeout() through the use of onSingleTapConfirmed. Is this an okay change or should I rely on onSingleTapUp instead?

DavidGrath · 2026-04-21T06:53:34Z

@thompson-tomo , please how do the changes look?

thompson-tomo · 2026-04-21T08:38:29Z

+                val buttonStateInt = motionEvent.buttonState
+                val toolTypeHasButtons = toolTypeInt == MotionEvent.TOOL_TYPE_MOUSE || toolTypeInt == MotionEvent.TOOL_TYPE_STYLUS
+                val isButtonPrimary = buttonStateInt == MotionEvent.BUTTON_PRIMARY || buttonStateInt == MotionEvent.BUTTON_STYLUS_PRIMARY
+                if(toolTypeHasButtons && !isButtonPrimary) {
+                    return false
+                }
+                val buttonState = buttonStateToString(buttonStateInt)
+
+                if(buttonState != null) {
+                    appEvent.setAttribute(HARDWARE_POINTER_BUTTON, buttonState)
+                }


Not sure if we need to restrict it to primary given we already have an attribute to indicate which button.

Suggested change

val buttonStateInt = motionEvent.buttonState

val toolTypeHasButtons = toolTypeInt == MotionEvent.TOOL_TYPE_MOUSE || toolTypeInt == MotionEvent.TOOL_TYPE_STYLUS

val isButtonPrimary = buttonStateInt == MotionEvent.BUTTON_PRIMARY || buttonStateInt == MotionEvent.BUTTON_STYLUS_PRIMARY

if(toolTypeHasButtons && !isButtonPrimary) {

return false

}

val buttonState = buttonStateToString(buttonStateInt)

if(buttonState != null) {

appEvent.setAttribute(HARDWARE_POINTER_BUTTON, buttonState)

}

val toolTypeHasButtons = toolTypeInt == MotionEvent.TOOL_TYPE_MOUSE || toolTypeInt == MotionEvent.TOOL_TYPE_STYLUS

val buttonState = null

if(toolTypeHasButtons) {

val buttonStateInt = motionEvent.buttonState

buttonState = buttonStateToString(buttonStateInt)

}

if(buttonState != null) {

appEvent.setAttribute(HARDWARE_POINTER_BUTTON, buttonState)

}

Okay, I'll need to delete the corresponding test I wrote for this as well

Sure, note the change should be replicated to single click.

thompson-tomo · 2026-04-21T11:14:26Z

            .logRecordBuilder()
            .setEventName(name)

    private fun createViewAttributes(view: View): Attributes {


Should we also be adding the hw.pointer.* attributes on her as well?

I think it might not be necessary, since app.screen.click is always sent

And it already has the same attributes

That is true but I was thinking of the use case of where the collector is filtering events and might filter out app.click hence the view click event should be self sufficient.

cleverchuk

May need to standardize the new attributes in semconv otherwise LGTM!

fractalwrench · 2026-04-21T15:58:10Z

+                    .setAttribute(HARDWARE_POINTER_CLICKS, 2)
+                    .setAttribute(HARDWARE_POINTER_TYPE, toolType)
+
+                val toolTypeHasButtons = toolTypeInt == MotionEvent.TOOL_TYPE_MOUSE || toolTypeInt == MotionEvent.TOOL_TYPE_STYLUS


I would consider driving this and other information via an enum in ViewUtils as that will reduce the amount of logic in this class. Here's a non-exhaustive example of what I mean:

enum class TapEvent( val motionEvent: Int, val toolType: Int, ) { val toolTypeDescription: String // derive from MotionEvent.TOOL_TYPE_* val hasButtons: Boolean = toolTypeInt == MotionEvent.TOOL_TYPE_MOUSE || toolTypeInt == MotionEvent.TOOL_TYPE_STYLUS }

Thank you, I've applied the other suggestions. I'll look into this and give my feedback by Wednesday or Thursday

Co-authored-by: Jamie Lynch <fractalwrench@gmail.com>

Added basic double-tap, based off view click

3b43281

DavidGrath requested a review from a team as a code owner April 9, 2026 20:39

Made fixes to correct failures to checks

a051d4a

Ran apiDump

ae74e2a

thompson-tomo reviewed Apr 11, 2026

View reviewed changes

DavidGrath added 3 commits April 16, 2026 21:33

Merge branch 'main' into issue-1642-double-tap

838d198

New hardware attributes: pointer, clicks, and button. Single tap and …

fc26fa0

…double tap both now rely on `GestureDetector`

Make detekt and apiDump happy

7c58c18

thompson-tomo reviewed Apr 21, 2026

View reviewed changes

Removed primary button exclusivity from double-tap

75c1407

thompson-tomo reviewed Apr 21, 2026

View reviewed changes

cleverchuk approved these changes Apr 21, 2026

View reviewed changes

$fractalwrench$

fractalwrench reviewed Apr 21, 2026

View reviewed changes

$@fractalwrench$

Apply suggestions from code review

7c2d59c

Co-authored-by: Jamie Lynch <fractalwrench@gmail.com>

		internal const val APP_SCREEN_DOUBLE_TAP_EVENT_NAME = "app.screen.doubletap"
		internal const val VIEW_DOUBLE_TAP_EVENT_NAME = "app.widget.doubletap"

Conversation

DavidGrath commented Apr 9, 2026

Uh oh!

linux-foundation-easycla Bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DavidGrath commented Apr 9, 2026

Uh oh!

DavidGrath commented Apr 10, 2026

Uh oh!

codecov Bot commented Apr 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DavidGrath commented Apr 18, 2026

Uh oh!

DavidGrath commented Apr 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thompson-tomo Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cleverchuk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

linux-foundation-easycla Bot commented Apr 9, 2026 •

edited

Loading

codecov Bot commented Apr 11, 2026 •

edited

Loading

thompson-tomo Apr 21, 2026 •

edited

Loading