The input queue runs concurrent with the native activity lifecycle,
and so the getKey helper Java method might be called after the
app has been destroyed. This is particularly likely for "back"
key presses that destroys activities.
Change the getKey method to be static so that it can be called
outside the app lifecycle.
Run `go generate ./cmd/gomobile` to update the compiled dex file that
contains GoNativeActivity.
Fixesgolang/go#27652
Change-Id: Id2c863ee07e5447f033e67d6948fbfe746916ffa
Reviewed-on: https://go-review.googlesource.com/135215
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This is only the first half of physical key event mapping. The
modifiers and hardware key codes will be in a followup CL. I'm
splitting this out because it covers two other parts of the problem:
first is maintaining a JNIEnv pointer for the main routine, the
second is access to the Android unicode key map. The NDK does not have
a method to give us the key mapping, so we get to it via
GoNativeActivity.
Tested with a USB keyboard. I'll attempt an abd-based unit test later,
but I suspect it will be difficult to set a device ID.
Change-Id: Ie93700d1f2a5d382a9b17cdd668cb4acaa6e4bcc
Reviewed-on: https://go-review.googlesource.com/13649
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Subclassing NativeActivity makes two things possible. Firstly, we can
implement an InputConnection to offer good support for IMEs,
necessary for good keyboard support. Secondly, we can use it to
overlay WebViews onto the NativeActivity.
But to sublcass NativeActivity, we need to compile Java. To keep the
toolchain go gettable, this is done with go generate.
While here, check the exception after FindClass. Apparently it can
throw an exception.
Updates golang/go#9361.
Updates golang/go#10247.
Change-Id: I672545997f0c9a7580f06988a273c03404772247
Reviewed-on: https://go-review.googlesource.com/11980
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
