Working implementation of allowsHitTest() on Android

[tifroz]

This PR competes with #354. #354 is a very limited/local bug fix. This PR is closer to a full implementation of allowsHitTest() on Android

Current implementation (Android behavior):

• button1 over button2 => button1 handle the tap
• button1.allowsHitTest(false) over button2 => button1 disabled + swallows the tap (no-one handles it). THIS IS WRONG
• text1 over button2 => button2 handle the tap
• text1.allowsHitTest(false) over button2 => text1 swallows the tap (no-one handles). THIS IS WRONG

#354

• button1 over button2 => button1 handle the tap
• button1.allowsHitTest(false) over button2 => button1 handle the tap. THIS IS WRONG
• text1 over button2 => button2 handle the tap (unless text1 has a tap handler)
• text1.allowsHitTest(false) over button2 => button2 handles the tap

This PR (as tested)

• button1 over button2 => button1 handle the tap
• button1.allowsHitTest(false) over button2 => button2 handle the tap.
• text1 over button2 => button2 handle the tap (unless text1 has a tap handler)
• text1.allowsHitTest(false) over button2 => button2 handles the tap (regardless of tap handler on text1)

Skip Pull Request Checklist:

• REQUIRED: I have signed the Contributor Agreement
• REQUIRED: I have tested my change locally with swift test
• OPTIONAL: I have tested my change on an iOS simulator or device
• OPTIONAL: I have tested my change on an Android emulator or device
• REQUIRED: I have checked whether this change requires a corresponding update in the Skip Fuse UI repository (link related PR if applicable)
• OPTIONAL: I have added an example of any UI changes in the Showcase sample app

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.

Codex generated the code under supervision. Tested manually from a native sandbox app

[marcprux]

Thanks for continuing to work on this.

One note is that I needed to implement a similar feature to get the new contextMenu() modifier to work on a Button element: #360. I wonder if using that technique would work here as well, and obviate the need for the custom HitTesting.kt node…

[marcprux]

Need to remove print statement (you could change this to a Log.debug() call if you think it is useful).

[marcprux]

Another print statement that needs to be removed.

[tifroz]

I am new to the Android universe, so please take with a grain of salt:

As I understand it, pointerInput could help when the competing handlers are in the same event chain (typically parent-child), because you can choose pass/consumption behavior. It would not help however when the overlapping views are siblings, a fairly common scenario (e.g. in a ZStack)

Will clean up the logs + gate the new RenderContextMenu with _isHitTestingEnabled (so the contextual menu doesn't show when hit testing is disabled)

[marcprux]

LGTM. Thanks for all the work on it!