Problem with AC_BACK with Urho3D app in Android

[weitjong]

Below is my understanding on how the AC_BACK and AC_HOME keys should behave, the former should pause the activity (OpenGL context lost) and destroy the activity (SDL exits main thread), while the latter should just pause the activity without destroying it. In a single activity app, however, both cases will show user the "home screen" afterwards. The subtle difference is, when user resuming the app, the former would need to recreate the SDLMain thread and reinitialize the app, while the latter just need to recreate the OpenGL context and could resume the app state from where it was before. I am new in Android development, so please correct me if my above understanding is wrong.

The AC_BACK key is currently not being handled by SDL internally. Instead it is being handled by Urho3D::Input class where it aliases the AC_BACK with ESC key. And as per usual my Urho3D app handles ESC key down by exiting the Urho3D engine. This would exit the SDL main thread and in turn cause a pause and destroy cycle on Java side. This is well and good when the app does not have other threads running. In my project, I am integrating Urho3D with another 3rd party library which may execute other tasks in another thread at the same time as SDLMain thread. In this scenario, pressing the AC_BACK key may not be able to exit the app cleanly. I am observing more often than not that it has caused a signal 11 segfault instead of normal pause & destroy cycle.

This is just my suspicion though. So, I tried to solve the problem by changing the code for onKey() in SDLActivity java class to read:

    // Key events
    @Override
    public boolean onKey(View  v, int keyCode, KeyEvent event) {
       
        if (keyCode == KeyEvent.KEYCODE_BACK) {
            return false;
        }
        else if (event.getAction() == KeyEvent.ACTION_DOWN) {
            //Log.v(TAG, "key down: " + keyCode);
            SDLActivity.onNativeKeyDown(keyCode);
            return true;
        }
        else if (event.getAction() == KeyEvent.ACTION_UP) {
            //Log.v(TAG, "key up: " + keyCode);
            SDLActivity.onNativeKeyUp(keyCode);
            return true;
        }
       
        return false;
    }

Basically, it does not let SDL to handle the AC_BACK and let the Activity class to handle the event. With this change, I am observing my app exits cleanly every time reliably. The pause and destroy cycle should eventually send the nativePause and nativeQuit signal to SDL and Urho3D to exit gracefully without the need to handle the ESC key explicitly.

Any other thought on what might be the cause for the signal 11 and its resolution instead of what I have done? Should I check in my change to Urho3D/SDL fork?

[Lasse Öörni]

The idea to pass the AC_BACK (or ESC) to Urho's input is to allow the application to choose not to quit outright, but to eg. display an exit confirmation dialog first.

Could you try modifying Engine::Exit() to post a message to the Java side telling it to quit cleanly, instead of terminating the SDL main thread? Some things like changing the application window title in SDL/Android already have a mechanism for that, so you might be able to reuse that.

[Lasse Öörni]

In fact there's already a mechanism for requesting finish activity from the C++ side, it just fell to disuse when SDL was updated. I'll try what happens when using it.

[Lasse Öörni]

If you try the SVN head now, Engine::Exit() is routed through the Java activity now.

If it still crashes, then I see no option but to let SDLActivity pass false for the AC_BACK key and let the activity terminate on its own.

[weitjong]

Thanks Lasse. I almost come up to the same the code as yours separately. I have, however, removed the second finishActivity() from being called on the Java side when the SDL main thread exit. The tests are all good so far :)