Crash when closing soft keyboard while using native activity

Question

We are developing an indie game for android and would like the user to choose his nickname. We have chosen to use the Native Activity that is provided by the NDK as that seemed to be the easiest way to go.

The first problem we've encountered with the keyboard was that the function ANativeActivity_showSoftInput() seems to do nothing at all (as described e.g. here), so we bring up the keyboard using JNI calls to function:

static void showKeyboard(Activity activity) {
  String s = Context.INPUT_METHOD_SERVICE;
  InputMethodManager m = (InputMethodManager)activity.getSystemService(s);
  View w = activity.getWindow().getDecorView();
  m.showSoftInput(w, 0);
}

This works fine for bringing up the keyboard, and works fine on some devices all together. But on other devices (e.g. Nexus 7), when the user tries to close the keyboard by hitting the "hide keyboard" button the application freezes with this debug output:

I/InputDispatcher(  453): Application is not responding: AppWindowToken{429b54a8 token=Token{42661288 ActivityRecord{41bb0b00 u0 com.example.project/android.app.NativeActivity}}} - Window{420d6138 u0 com.example.project/android.app.NativeActivity}.  It has been 5006.7ms since event, 5005.6ms since wait started.  Reason: Waiting because the focused window has not finished processing the input events that were previously delivered to it.
I/WindowManager(  453): Input event dispatching timed out sending to com.example.project/android.app.NativeActivity

And then the user is presented with a dialog box saying:

Project isn't responding. Do you want to close it? [Wait]/[OK]

Is there something we are doing obviously wrong? Or might this be a bug? Issues like this one seem to suggest keyboard functionality has never been properly implemented in the native glue.

On a side note, we havent tested on many devices yet, but the ones where it doesn't crash are ones with an older android OS. Also, on those where it does crash, when the keyboard appears, it changes the back button from one that looks like this to one that looks like this . Perhaps that corresponds to a different input event that wasn't accounted for when they first developed the native glue? I'm just guessing .

Anyway, if someone got soft keyboard working while using native activity, please let us know how you've done it.

Cheers

UPDATE

It has been reported as a bug in Android here, we would still be happy to hear about workarounds though. If you are also affected by it, you might want to cast a vote on that issue (by pressing the star).

Answer 1

Peter's solution works well. However if you don't want to modify the native_app_glue file: notice that process_input is assigned as a function pointer. In your implementation file, create your own process_input functions as described by Peter:

static void process_input( struct android_app* app, struct android_poll_source* source) {
    AInputEvent* event = NULL;
    if (AInputQueue_getEvent(app->inputQueue, &event) >= 0) {
        int type = AInputEvent_getType(event);
        LOGV("New input event: type=%d\n", AInputEvent_getType(event));

        bool skip_predispatch
              =  AInputEvent_getType(event)  == AINPUT_EVENT_TYPE_KEY
              && AKeyEvent_getKeyCode(event) == AKEYCODE_BACK;

        // skip predispatch (all it does is send to the IME)
        if (!skip_predispatch && AInputQueue_preDispatchEvent(app->inputQueue, event)) {
            return;
        }

        int32_t handled = 0;
        if (app->onInputEvent != NULL) handled = app->onInputEvent(app, event);
        AInputQueue_finishEvent(app->inputQueue, event, handled);
    } else {
        LOGE("Failure reading next input event: %s\n", strerror(errno));
    }
}

At the beginning of your android_main function, assign your version of process_input to android_app->inputPollSource.process.

In your event handler make sure you check for the back key (AKEYCODE_BACK) and intercept it to hide your keyboard if visible.

Note that this problem appears to exist in Android 4.1 and 4.2 - solved in 4.3