I have a weird problem with Jetpack Compose on and...
# compose-android
j
I have a weird problem with Jetpack Compose on android 10-based devices from specific vendor (but just one model) - when I switch to home screen and then back to compose application all touch events lag by one. I touch a button on the left and the one on the right reacts if it was pressed before, then I touch anywhere and the left one reacts. This happens only on those devices and even with official android compose sample applications (so I ruled out that I'm using it wrong). I tried logging touch events in Activity's
dispatchTouchEvent
method and the coordinates are correct and correspond to me touching the screen in those places at that time. Also non-compose applications also run fine. How can I further debug what is messing with compose or providing wrong input? How does it even acquire touch events from the system?
Actually when I long touch the screen, the wrong button gets highlighted as long as I touch the screen, so it seems compose gets the events right when they happen, but for some reason uses target at previous coordinates instead of current. I can't imagine how this could be possible and why it's broken only on those devices. Anybody familiar enough with compose architecture to point me where I could start tracing how the event is processed from entering compose to the decision which node should react to it?
Ok, I've figured it out - compose gets events by overriding
dispatchTouchEvent
and
dispatchGenericMotionEvent
in
AndroidComposeView
When I pressed home, the device was generating a sequence of:
Copy code
MotionEvent { action=ACTION_HOVER_ENTER, ... }
MotionEvent { action=ACTION_HOVER_ENTER, ... }
MotionEvent { action=ACTION_HOVER_MOVE, ... }
MotionEvent { action=ACTION_HOVER_EXIT, ... }
which I guess was baffling compose.
z
Feel free to file a bug, and mention which device this happens on.
m
@Janusz Chorko have you come to a solution on this issue? I have experienced the same root issue on S700 readers from Stripe. It happens only on SDK 29 and 30. Seems to be that when the device is overwhelmed with touch events there is an internal error causing touch events handled by Android to become offset by 1 from the events as Compose sees them. In SDK > 30 the events stop registering until the device catches up and is able to handle all buffered events in order. Our theory was an error with MutableInteractionSource but even using a custom pointerInput implementation we still see the bug. It is bizarre that we have only been receiving complaints about this issue since early-mid March. We noticed that Stripe updated our reader February 16th, they may have updated the device to a patch version of Android 10 that introduced the bug.