When having a window that deals with input (text fields, text areas, etc.), the QPA will manage a QtEditText under such window, and that will manage a QtInputConnection. The input connection might send callbacks to update the text field content on the Android side if it has changed or handles positions or text composing status. To get such details from Qt side, we invoke a blocking native call to the Qt UI thread. At the moment, AndroidDeadlockProtector is used to avoid cases where multiple calls want to run on the QtThread and block each other. That works for the most part except one case, where the QAndroidPlatformOpenGLWindow::eglSurface() is involved, in such case, if egl surface can't acquire the QtThread lock then the app exists with a qFatal() error.

That last case is what's happening, especially when dealing with text fields auto tests. The situation is that a QtInputConnection will invoke a blocking to QtThread just before destroying the QtEditText and the window, and then attempting to create another window. See logs from tst_qquicktextfield.txt.

So far there were two patches https://codereview.qt-project.org/c/qt/qtbase/+/670302 and https://codereview.qt-project.org/c/qt/qtbase/+/670700 added to reduce the likelihood of blocking calls from QtInputConnection in invalid states and thus the likelihood of blocking eglSurface() call. What those fixed are situations where the QtInputConnection methods are called when having an invalid focus object or a focus object that doesn't really deal with any input methods.

In addition to this, some tests like tst_qquicktextfield would still fails when only checking the focus object, for those a further check is done to avoid the blocking call to QtThread from QtInputConnection if no keyboard is being shown, this usually works because it's expected to have the keyboard shown to properly interact with those input fields. Although, this is not the best thing, it's more like a workaround.

To fix this issue altogether, I think it's important to avoid such blocking calls altogether, we could potentially achieve that by having Qt cache its text fields states and details when ever it's done and then QtInputConnection mainly fetches these caches without having to block QtThread.