Avoid deadlock with two consecutive suspended notification

According to our Android app test, sometimes we will receive two
consecutive app suspended notifications. In the second app suspended
notification QWindowSystemInterface::flushWindowSystemEvents() will
deadlock due to the fact that the event dispatcher has been stopped in the
first app suspended notification. This patch will simply return if we
found the event dispatcher has been stopped in the beginning of app
suspended notification.

Change-Id: I15fa4a6a118510b866ff16061862f4bb8360cc9b
Reviewed-by: BogDan Vatra <bogdan@kde.org>

1 files changed, 7 insertions, 0 deletions

diff --git a/src/plugins/platforms/android/androidjnimain.cpp b/src/plugins/platforms/android/androidjnimain.cpp
index 1c157c79c3..00ef8f670a 100644
--- a/src/plugins/platforms/android/androidjnimain.cpp
+++ b/src/plugins/platforms/android/androidjnimain.cpp
@@ -593,6 +593,13 @@ static void updateApplicationState(JNIEnv */*env*/, jobject /*thiz*/, jint state
         return;
 
     if (state <= Qt::ApplicationInactive) {
+        // NOTE: sometimes we will receive two consecutive suspended notifications,
+        // In the second suspended notification, QWindowSystemInterface::flushWindowSystemEvents()
+        // will deadlock since the dispatcher has been stopped in the first suspended notification.
+        // To avoid the deadlock we simply return if we found the event dispatcher has been stopped.
+        if (QAndroidEventDispatcherStopper::instance()->stopped())
+            return;
+
         // Don't send timers and sockets events anymore if we are going to hide all windows
         QAndroidEventDispatcherStopper::instance()->goingToStop(true);
         QCoreApplication::processEvents();