Crashes in Ensemble Choice Box are reported on Android:
https://bitbucket.org/javafxports/android/issue/11/ensemble8-sample-controls-choice-box

After looking into it, I noticed clicking an item in a choice box sometimes works and sometimes fails.
The failing function is glass_application_notifyMouseEvent in LensApplication.c

I compared the log output, and in the case it works, the touch event is correctly handled, and the popupwindow is released. Immediately after this, another event is processed but immediately skipped due to "skipping notifyTouchEvent with NULL view". This happens in case window->isEnabled and window->view == NULL or window->view->lensView is NULL.

In the case of failure, the window->isEnabled is false, and a FOCUS_DISABLED event is sent to the window (line 542). However, I added some debugging and it turns out that the window that is about to receive a FOCUS_DISABLED event is the window that was freed previously:

I/GLASS (32709): freeing window (0x5fb60770)
[skip]
I/GLASS (32709): Window 7143535[0x5fb60770] is disabled - sending FOCUS_DISABLED event
V/GLASS (32709): JNI call notifyWindowEvent for lens 0x4013a594 and event 545
W/dalvikvm(32709): Invalid indirect reference 0x4013a594 in decodeIndirectRef

I didn't look much deeper in the code yet, but it doesn't sound right to me that a window that is being freed is still candidate for getting events?