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.