Status Update
Comments
lp...@google.com <lp...@google.com> #2
Seems I don't have access to move this to component 1237242 which seems to be for UI automator, could you help move this issue to the correct component / triage? Thanks!
pe...@google.com <pe...@google.com> #3
Can you try with androidx.test.uiautomator:uiautomator:2.3.0-alpha01? There are some fling/gesture improvements which might have already fixed this.
to...@gmail.com <to...@gmail.com> #4
Just tested 2.3.0-alpha01 on my app (full compose) and it's the same maybe more than 50% of the fling(direction) are made as click.
Edit: in the logs fling(bounds=Rect(607, 1671 - 989, 1727),direction=RIGHT,speed=26250)
fling(bounds=Rect(61, 1908 - 1295, 2025),direction=UP,speed=26250)
fling(bounds=Rect(382, 303 - 871, 359),direction=UP,speed=26250)
to...@gmail.com <to...@gmail.com> #5
As a test I've switched to swipe(inverteddirection, 1f).
This result in 25% click, 25% proper fling, 50% micro swipe of a few pixels.
The swipe call always returns after less than 100ms and device.waitForIdle() does not work to wait for the end so the clicks after are eaten to stop the swipe.
Can't find a proper stable way to scroll content with Compose.
pe...@google.com <pe...@google.com> #6
From the logs in
UiAutomator injects 1 motion events every 8ms, so you're likely just getting the start and end events (basically equivalent to a click).
You should try either on a larger object (some parent container?) or reducing the speed.
On our end, we should log a warning for cases like this and investigate reducing the delay between motion events.
to...@gmail.com <to...@gmail.com> #7
Missed your message, I forget to star. Auto subscribing when commenting should be the default :(
About the size and speed it's what a fling(object) gives (7500 * density). Since it's a full compose app the lazy lists and everything have no real reason to have a semantic and for the moment I did not need to enable the tag to resId trick so avoided it. Maybe it's necessary so or I could try to use the parent. (But sometimes I face a Stale error when accessing parent due to recomposition)
About manual speed the thing is that I have no idea why the default is 7500 and what would be a proper value for those cases. Is there some docs somewhere to workaround the issue for now ?
pe...@google.com <pe...@google.com> #8
Not sure if there's any good docs on this, but you can find the fling velocity range in
Based on that, you should be able to reduce the speed significantly (e.g. 500px/s) and still have it registered as a fling.
to...@gmail.com <to...@gmail.com> #9
Ok thanks, so after some tests 500px does not work but using the parent and 15000 works on that particular device (still random fails with default) I can now reliably generate the baseline profiles on one device.
Will need to figure out more or to have working values when I automate this a little more.
Would 'investigate reducing the delay between motion events.' be part of this issue so I'll get update if it's done from here ?
Description
Note: this needs rerouting to the correct team as UiAutomator doesn't have an issue tracker as far as I can see!
The issue is that nested scrolling causes the fling gesture to sometimes click items instead of performing any kind of scroll.
I've attached a (slightly) modified version of android-performance which demonstrates the issue. I just embedded the compose-based feed inside of a non-Compose bottom sheet (+ wired up nested scrolling).
Now when you run the
scrollFeed
macrobenchmark test, instead of flinging the feed, about 50% of the time the feed items will get clicked instead.Any fix or workaround would be really welcome as this setup closely mimics our real app! Thanks in advance.