AndroidView inside ComposeView: touch dispatch order between View and Compose pointer input

Dispatch Order and Priority

In a Jetpack Compose hierarchy, the AndroidView acts as a bridge. Because the embedded View remains a member of the traditional Android View system, the embedded View typically sees and processes touch events before the surrounding Compose pointerInput modifiers.

When a touch event occurs, the ComposeView (the root of the Compose tree) receives the event from the Android system. It then dispatches it down to the embedded AndroidView. If the legacy View's onTouchEvent returns true, the event is considered consumed by the View system and will not trigger the Compose pointerInput chain for that specific event stream.

Mechanism for Claiming or Yielding Gestures

To manage the boundary between the two systems, use these established Android View mechanisms:

• To Claim: The embedded View must return true from onTouchEvent. This signals to the parent ComposeView that the event has been handled.
• To Yield: The embedded View should return false from onTouchEvent. This allows the event to bubble back up to the Compose pointer input system.
• To Prevent Parent Interception: If the AndroidView is nested inside a Compose scrollable container (like LazyColumn), the View should call requestDisallowInterceptTouchEvent(true) on its parent. This prevents the Compose-based scroll container from stealing the gesture stream once the View has started tracking a gesture.

Verification Method

Logging touch coordinates and event types is the standard and accepted way to verify this ordering. There is no public "test hook" API for the internal ComposeView dispatch logic. To verify your specific implementation, implement the following:

1. Add a Log.d statement inside the onTouchEvent of your custom View.
2. Add a Log.d statement inside the awaitPointerEventScope of your Compose pointerInput modifier.
3. Observe the Logcat sequence: the View log should appear before the Compose log for a single touch down event.

Assumptions and Constraints

This behavior is consistent across API levels 21–34 because the bridge relies on the fundamental View.onTouchEvent contract. However, this assumes the AndroidView is not wrapped in a Box or other Compose layout that has already consumed the pointer event via a pointerInput modifier higher up in the tree, as Compose's own internal propagation (downward then upward) occurs before the event is handed off to the legacy View system.

Missing Diagnostic: Are you using a scrollable Compose container (e.g., Modifier.verticalScroll) as a parent to the AndroidView? If so, the parent may intercept the event before it ever reaches the embedded View.