Essentially the GameActivity backend doesn't have checks within its Java Activity callbacks that check whether the android_app has already been destroyed (e.g. due to a graceful exit by returning from android_main
Since android-activity will issue a GameActivity_finish when android_main returns that will result in onPause -> onStop -> onDestroyed lifecycled events in Java after the native thread for android_main has exit and then because the GameActivity callbacks don't check if the android_app is detroyed they deadlock waiting for the native thread to handle these lifecycle events.
See the discussion here for more context: https://github.com/rust-mobile/android-activity/pull/94#issuecomment-1652014915
Essentially the GameActivity backend doesn't have checks within its Java Activity callbacks that check whether the
android_apphas already been destroyed (e.g. due to a graceful exit by returning fromandroid_mainSince
android-activitywill issue a GameActivity_finish when android_main returns that will result inonPause -> onStop -> onDestroyedlifecycled events in Java after the native thread forandroid_mainhas exit and then because the GameActivity callbacks don't check if theandroid_appis detroyed they deadlock waiting for the native thread to handle these lifecycle events.