IssueTracker

Hi, thanks for reporting this. Please update this ticket with a reproducible code/sample so we can better investigate the issue.

Thanks!

The endless joy of support tracker ....

So I'm actually asking a question ... So instead of insta closing without reading anyway to have someone read and answer?

What / Where are the settings that controls the velocity calculations.

Compose animations are tied to Android dev settings animation scale. What is the equivalent here.

Not all compose animations are tied to Android developer settings.

Fling animations in lists are no longer controlled by the Settings menu and cannot be overriden, so that shouldn't be source of the problem you're seeing. This has been solved in https://issuetracker.google.com/241460890 which was released in 1.4.0-alpha01.

The velocity calculation for lists is done at the draggable level and are also transparent to developers, so you cannot control how these are calculated.

A sample/reproducible code is required if I was to move forward with investigating this issue.

I don't have a repro and can't build one, the app is in prod and working for thousands of other users. https://play.google.com/store/apps/details?id=app.symfonik.music.player&hl=fr&gl=US For that user every single lists are impacted. I'm not using refresh layout.

Is there any other changes in Compose 1.4 that could impact the velocity calculation?

There weren't new changes on how velocity calculation is determined AFAIK.

I don't know which components you're using (Jetpack Compose component(s) used: Most of them) so I can't narrow down the possibilities here.

Well I do use a tons of components and since all the lists in all the screens are impacted, I can't narrow down the components too, since there's never the same except the LazyXXX ;)

I can do the narrowing down, the research and everything as I did when passing countless hours helping fixing other Compose bugs, including some major mem leaks and for many other components since 11 years, but sometimes it requires some cooperation from the other side.

Without a clue on where to start on what can impact this I can't. And for the moment it seems like I'm trying to pull your teeth when trying to get some help.

Hi, unfortunately we can not investigate this issue more without further information. We understand this is frustrating. As far as we can tell from the video, there is no obvious cause related to Jetpack Compose, and the issue could be related to an OEM-specific implementation, a hardware malfunction or something entirely different. This theory is corroborated by you having only one bug report by one user, and no other developer having reported anything similar so far.

Bugs that are not caught by our tests typically appear because of API usage that we did not consider. As such, to attempt to reproduce the issue, we would need to learn more about the usage of the APIs.

As mentioned by my colleague above, fling animations in lists are not controlled through the settings menu. We do not see any obvious places to start the debugging process, but are happy to investigate once we have more supporting information.

For the time being, we will keep the ticket closed unless we have enough information to investigate.

I know my English is not that good, but I perfectly know that you can't investigate without more info.

I'm asking for clues for me to try to investigate with the user and be able to provide that info. User is slow to answer but can generate logs and I can log whatever could help if I knew what.

Seems there's none so let's hope someone else can, probably when 1.4 is released.

The user have no issues in other apps, and did not have issues in this app until a few release back.

One thing I can think of is if you're overriding the Lazy component's fling behavior with an implementation different from the default one, then you will be susceptible to android dev settings change. If that is the case you'd need to override the motionScale like we did for the Default fling behavior: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt;l=538 If you want additional confirmation that this is not the source of the issue you can also log the animation scale factors that the user is using by calling coroutineContext[MotionDurationScale]?.scaleFactor inside a coroutine scope/ suspend function.

One other thing you could do is to add a NestedScrollConnection (using the nestedScroll modifier) around your Lazy component and check/log the deltas that are being dispatched in the onPreFling method in comparison with the deltas of a working phone.

Thanks I'm still using Snapper on some horizontal lists as first official version was not that good, might try to migrate again as I saw commits talking about improvements, but it's not the case in the other pages.

I'll log the MotionScale during the fling too.

I'm already using a nestedScroll to show/hide the top bar with only handling the onPostScroll and returning Offset.Zero.

Adding the onPreFling logs gives: (MotionScale available and return value

onPreFling: (MS:1.0) (0.0, 7710.2617) px/sec -> (0.0, 0.0) px/sec
onPreFling: (MS:1.0) (0.0, -19162.34) px/sec -> (0.0, 0.0) px/sec

Are the return values normal? And I suppose on his device the first value will be small?

Will send him a test APK with those logs to see.

From the logs your motion scale is 1, so if the user has turned animations off this will be zero and we'll have the root case.

Yeah, from this logs it looks like normal fling on different directions and in your user this might be small (if this is the cause of the issue).

Let us know what you find out and we'll go from that, thanks!

Ok so the user was actually reactive this time.

borneo_retail/borneo/30/11/moto g power (2021)/motorola DisplayMetrics{density=1.9125, width=720, height=1484, scaledDensity=1.9125, xdpi=268.941, ydpi=267.368}

2023-02-17 09:31:07.326 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 6244.2603) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:07.936 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 2908.9268) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:08.537 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 4689.1943) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:09.139 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 1548.649) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:09.722 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 3819.7192) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:10.242 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 4818.6904) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:10.827 Verbose/Debug: onPreFling: (MS:1.0) (0.0, 5134.658) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:12.753 Verbose/Debug: onPreFling: (MS:1.0) (0.0, -3554.5596) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:13.437 Verbose/Debug: onPreFling: (MS:1.0) (0.0, -2132.1245) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:14.011 Verbose/Debug: onPreFling: (MS:1.0) (0.0, -2103.9492) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:14.562 Verbose/Debug: onPreFling: (MS:1.0) (0.0, -5271.67) px/sec -> (0.0, 0.0) px/sec
2023-02-17 09:31:15.093 Verbose/Debug: onPreFling: (MS:1.0) (0.0, -2765.7136) px/sec -> (0.0, 0.0) px/sec

The values looks the same to me :(

So luckily the user really really like the app and is willing to do tons of tests.

I've made builds reverting compose from 1.4.0 alpha 01 with M3 "1.1.0-alpha01" to current versions of compose without changing M3. (A little painful since I updated all the deprecations during my updates that I needed to revert)

The regression occurs between 1.4.0 alpha 02 and 1.4.0 alpha 03. No other changes than that in the builds.

Since I can't repro the issue myself, it would be a little too much to ask the user to do a full dichotomic search a I would do.

Assuming the change would be in foundation: https://android.googlesource.com/platform/frameworks/support/+log/a1e318590b217ecfce1b2de17eed2f18b6a680bb..047e199bdcb8a5cd744cc7a2f986631bfb350ec7/compose/foundation

Possible related issues: https://android.googlesource.com/platform/frameworks/support/+/828bdbdc6c268dc6b9c9af00668f1a4fe8777611 https://android.googlesource.com/platform/frameworks/support/+/eddca21324d7e8d91a18b0aea74cabb673921c1d

https://android.googlesource.com/platform/frameworks/support/+/04dfd13bfce7db531781d6817c7e249ec71e8ebd (Even if not using those) https://android.googlesource.com/platform/frameworks/support/+/188c6adca18f41744f1ed69ada21170a65ffce43 (Even if not using those) https://android.googlesource.com/platform/frameworks/support/+/83984347dee20fbc3b8bcf30cf2f961cd4474579 (Even if not using those)

Would appreciate if you could help finding the related snapshot builds https://androidx.dev/snapshots/builds

Usually I use https://ci.android.com/builds/branches/aosp-androidx-main/grid? but since it's quite old and I have not found a way to search for commit it would take ages. If there's a way to figure out the commit easily, just tell me the way and I can do the mapping and the tests.

Furthermore since I have a repro by the user, a confirmation it's a compose regression and a target to search for I'd like to have this issue reopened if possible.

Bump, I have no way to identify the faulty commit without your help to get those snapshot ids.

The links link from gerrit https://android-build.googleplex.com/builds/sha-search/Ia834eccfcd8bd7eb1125478120f0844dbb6d2203?ref=gerrit&host=android&project=platform%2Fframeworks%2Fsupport are private to Google and can't be used by us.

The ci grid have no pagination and https://androidx.dev/snapshots/builds pagination require manual clicking to get the page tokens not a solution when there was like 1000 commits since A2 and tons of clicking to get the related commits each time.

Hey, here's the build ids you're looking for. I'm re-opening the ticket, though it's still a very broad area to search it seems we're narrowing it down.

828bdbdc6c268dc6b9c9af00668f1a4fe8777611 > build id = 9348446

eddca21324d7e8d91a18b0aea74cabb673921c1d > build id = 9261902

04dfd13bfce7db531781d6817c7e249ec71e8ebd > build id = 9321424

188c6adca18f41744f1ed69ada21170a65ffce43 > build id = 9307722

83984347dee20fbc3b8bcf30cf2f961cd4474579 > build id = 9304612

Thanks (Still closed).

So no way for me to be more autonomous for the second wave of builds that will needed? I've sent him the test APKs.

So I guess we can thank the nice Canadian user who took a lot of time on this. (And me at the same time maybe)

I mostly reversed the pageToken for the snapshot list and did the dichotomy search.

The PR causing issue on his device (and his wife that have the exact same device) is https://android-review.googlesource.com/c/platform/frameworks/support/+/2323493 Sad no one was able to remember that one since it's clearly stated as change to velocity tracker.

As a reminder he have no issue on any other non Compose app on his device, so the platform way works there.

Hey, the change you linked was published on 1.4.0-alpha04 and you previously mentioned that the issue was between alpha02 and alpha03?

That change didn't raise any signals internally and externally (apart from your user's device) since it is a parity change with platform, but since you're saying they didn't have issues with other apps I'm going to try and get a hold of a similar device so I can try to reproduce the issue. In the meantime could you give me a barebones structure for one of the screens where the issue is happening so I can create a sample app that is close enough to yours to test when I get the device?

Thanks.

Yes the user mixed the APKs during the first tests as I sent him all of them at once.

Improved the process later with version display so he could not repeat the mistake.

I'm joining Layout inspector export (From Girafe A6) for one of the screen should give you everything and details.

The user report the exact same behavior on his wife phone (same device) with no other issues in any other apps.

Since he already passed a couple of hours on this, he agreed to run other test builds if you need to logs things if you know what. I'd really like this to be fixed in final 1.4 and stop chasing bugs and alphas. 1 year of doing this was exhausting I'd like some rest now that most of the other issues are fixed :)

Bump, RC is tagged :(

As I said I can do whatever debugging is necessary with the help of the user and would appreciate a way to move forward if you can't get the device.

Really love the communication and the feeling that external devs are important and partners as all the communications says ;)

Can you check https://android-review.googlesource.com/c/platform/frameworks/support/+/2475105 and see if that change would also be applied to the velocity tracker here?

If not can you check if that could be the cause, since from the bugs it's rare and touched the same kind of devices.

Thanks, since I don't really know what I'm looking for I attached the logs from the user.

And a simple fling from my device (P6 Pro):

One big difference I can see is the classification. All mine are: classification=AMBIGUOUS_GESTURE all his are classification=NONE

18:18:10.442 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861375, position=Offset(70.0, 2008.0), pressed=true, pressure=0.31746033, previousUptimeMillis=555861375, previousPosition=Offset(70.0, 2008.0), previousPressed=false, isConsumed=false, type=Touch, historical=[],scrollDelta=Offset(0.0, 0.0))
18:18:10.448 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_DOWN, actionButton=0, id[0]=0, x[0]=70.0, y[0]=2008.0, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=NONE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=555861375, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=980593719 }
18:18:10.464 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(false): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=70.0, y[0]=2008.0, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=2, eventTime=555861396, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=725713755 }
18:18:10.478 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861413, position=Offset(104.0, 1938.0), pressed=true, pressure=0.36507937, previousUptimeMillis=555861375, previousPosition=Offset(70.0, 2008.0), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861400, position=Offset(70.0, 2008.0)), HistoricalChange(uptimeMillis=555861408, position=Offset(87.0, 1974.0)), HistoricalChange(uptimeMillis=555861413, position=Offset(104.0, 1938.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.480 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=104.015724, y[0]=1937.9667, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=3, eventTime=555861413, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=461611088 }
18:18:10.492 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861421, position=Offset(134.1, 1859.6), pressed=true, pressure=0.41269845, previousUptimeMillis=555861413, previousPosition=Offset(104.0, 1938.0), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861417, position=Offset(122.0, 1901.0)), HistoricalChange(uptimeMillis=555861421, position=Offset(134.0, 1860.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.495 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=134.09256, y[0]=1859.6483, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=2, eventTime=555861421, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=598428426 }
18:18:10.509 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861444, position=Offset(169.1, 1637.2), pressed=true, pressure=0.5714286, previousUptimeMillis=555861421, previousPosition=Offset(134.1, 1859.6), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861425, position=Offset(144.0, 1822.0)), HistoricalChange(uptimeMillis=555861429, position=Offset(152.0, 1783.0)), HistoricalChange(uptimeMillis=555861433, position=Offset(158.0, 1745.0)), HistoricalChange(uptimeMillis=555861437, position=Offset(163.0, 1704.0)), HistoricalChange(uptimeMillis=555861442, position=Offset(168.0, 1660.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.513 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=169.06133, y[0]=1637.1816, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=5, eventTime=555861444, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=561305389 }
18:18:10.531 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861460, position=Offset(171.9, 1437.4), pressed=true, pressure=0.6984127, previousUptimeMillis=555861444, previousPosition=Offset(169.1, 1637.2), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861445, position=Offset(170.0, 1617.0)), HistoricalChange(uptimeMillis=555861450, position=Offset(173.0, 1568.0)), HistoricalChange(uptimeMillis=555861454, position=Offset(175.0, 1518.0)), HistoricalChange(uptimeMillis=555861458, position=Offset(174.0, 1466.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.535 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=171.88011, y[0]=1437.3815, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=4, eventTime=555861460, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=488565489 }
18:18:10.550 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861479, position=Offset(120.4, 1172.2), pressed=true, pressure=0.8253969, previousUptimeMillis=555861460, previousPosition=Offset(171.9, 1437.4), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861462, position=Offset(170.0, 1412.0)), HistoricalChange(uptimeMillis=555861466, position=Offset(165.0, 1355.0)), HistoricalChange(uptimeMillis=555861471, position=Offset(152.0, 1295.0)), HistoricalChange(uptimeMillis=555861475, position=Offset(142.0, 1236.0)), HistoricalChange(uptimeMillis=555861479, position=Offset(122.0, 1177.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.550 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=120.384636, y[0]=1172.1539, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=5, eventTime=555861479, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=516541290 }
18:18:10.570 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861504, position=Offset(0.0, 863.0), pressed=true, pressure=0.87301594, previousUptimeMillis=555861479, previousPosition=Offset(120.4, 1172.2), previousPressed=true, isConsumed=false, type=Touch, historical=[HistoricalChange(uptimeMillis=555861483, position=Offset(104.0, 1123.0)), HistoricalChange(uptimeMillis=555861487, position=Offset(87.0, 1070.0)), HistoricalChange(uptimeMillis=555861491, position=Offset(71.0, 1017.0)), HistoricalChange(uptimeMillis=555861495, position=Offset(46.0, 974.0)), HistoricalChange(uptimeMillis=555861500, position=Offset(25.0, 932.0))],scrollDelta=Offset(0.0, 0.0))
18:18:10.572 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_MOVE, actionButton=0, id[0]=0, x[0]=0.0, y[0]=863.0, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=AMBIGUOUS_GESTURE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=5, eventTime=555861504, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=989696186 }
18:18:10.573 Debug                   app.symfonik.music.player.debug      V  MediaGridKt$MediaGrid$1$1$1.invokeSuspend@89: pE: PointerInputChange(id=PointerId(value=15), uptimeMillis=555861508, position=Offset(0.0, 863.0), pressed=false, pressure=0.87301594, previousUptimeMillis=555861504, previousPosition=Offset(0.0, 863.0), previousPressed=true, isConsumed=false, type=Touch, historical=[],scrollDelta=Offset(0.0, 0.0))
18:18:10.575 Debug                   app.symfonik.music.player.debug      V  StartActivity.dispatchTouchEvent@377: dTE(true): MotionEvent { action=ACTION_UP, actionButton=0, id[0]=0, x[0]=0.0, y[0]=863.0, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, classification=NONE, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=555861508, downTime=555861375, deviceId=4, source=0x1002, displayId=0, eventId=866274337 }

So after a lot of pain due to java.lang.NoSuchMethodError: No static method AnimatedContent(Ljava/lang/Object;Landroidx/compose/ui/Modifier;Lkotlin/jvm/functions/Function1;Landroidx/compose/ui/Alignment;Lkotlin/jvm/functions/Function4;Landroidx/compose/runtime/Composer;II)V in class Landroidx/compose/animation/AnimatedContentKt; in 1.5 I made him test snapshot 9725230 and the issue is still present.

Attached same logs in case that other PR did change the events received.

Thanks for the logs, I'll take a look and report back.

Bump?

Hey, I took some time looking into the logs, the classification is not really a problem, even though it's different. In my own device the classification is None and I don't see the problem.

Something that caught my attention was that in one of the log files you sent I see a number of Cancel events in the middle of Move events. This might indicate that Motorola's implementation of the Root View is somehow canceling the move events. Any cancelation in the motion events will cause the inner draggable to emit a velocity of 0 to the fling system, which might explain the hiccups your user is seeing.

I'm assuming these events come from the Root Activity in your app and no compose hierarchy is outside of it, this is important because these events will have come straight from the system instead of another compose hierarchy that might send cancel events. If this assumption is correct and you'd like to confirm you might add markers to the logs to indicate the start/end of the flings. You can do this from a NestedScrollConnection around one of your lists. You can emit a log onPreScroll and another onPostFling, this should capture the whole range of a drag+fling movement. If in the middle of the movement you see a MotionEvent action cancel, then this indicates that the system is canceling the movement. The ideal log should be a down event followed by a series of move events and finally an up event.

If this is a device issue, you may ask the user if there has been a system update which might explain why they've only started seeing this recently.

In any case, let us know what you find out. Thanks.

If this is a device issue, you may ask the user if there has been a system update which might explain why they've only started seeing this recently.

That's the first thing I asked him when he report the issue, before doing all the investigation.

This is not hardware as 2 devices does this He have 0 issues on any other applications (But not sure he have other recent compose apps). Reverting to the commit just before that patch does fix the issue for those devices.

The app activity is just a single setContent{} there's no views or anything else and yes I added the logs there as requested.

I can add more logs to see the start and end but I suppose this would just confirm the cancel events, not the source if it happens outside of Compose.

Is there any change to have a workaround or something I can as an hack like filtering / rewriting the wrong events? I suppose a call or a system dialog during a drag would trigger a valid cancel event too?

Hi, we're still waiting for the device. In the meantime, we're addressing some fixes in our velocity tracker that may help you as well. We received a report of a case similar to yours (a single device, this time a watch). They reported that using our fix resolved the problem for them, so it might solve for your as well.

The fix is still being tested, so it hasn't landed as the default behavior, but you can still access it by flipping this flag to true: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/input/pointer/util/VelocityTracker.kt;l=688?q=VelocityTracker.kt