Keyboard immediately crashes after opening on Android Marshmallow 6.0

[Lurux]

When clicking on an input field in Android 6.0, the keyboard appears for a little bit, but a popup saying "Florisboard stopped working" appears immediately after.

Environment information

• FlorisBoard Version: 0.2.3
• Install Source: Github release, via apk
• Device: Wiko Freddy
• Android version, ROM: Marshmallow 6.0, Stock

Steps to reproduce

1. Install
2. Click on an input field (In any app I guess ?)
3. Enjoy

[patrickgold]

Thanks for reporting this issue. Your issue seems to be somehow connected with #40 , I will investigate this further.

[patrickgold]

I've just released v0.2.4, which adds a crash handler and allows you to copy the captured error log. It would be great if you could try out the new version and if it still instantly crashes, copy the error log and paste it here. This would help me a lot to find and eliminate the source of the crash. Thanks in advance!

[Lurux]

Sure, I'll do that as soon as I have some time. I'll inform you when this is done :)

[Lurux]

Hey there, here's the error log you asked for.

The specific message when I clicked on a text box was that Florisboard was in a crash loop and reverted to another keyboard in order to let me type. This is probably why there's several stacktraces.

~~~ 1606389854540.stacktrace ~~~

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()	at android.os.Handler.<init>(Handler.java:200)	at android.os.Handler.<init>(Handler.java:114)	at android.widget.ViewFlipper$2.<init>(ViewFlipper.java:214)	at android.widget.ViewFlipper.<init>(ViewFlipper.java:214)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:73)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:63)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:62)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.createTabViewFor(MediaInputManager.kt:182)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.access$createTabViewFor(MediaInputManager.kt:50)	at dev.patrickgold.florisboard.ime.media.MediaInputManager$onRegisterInputView$1.invokeSuspend(MediaInputManager.kt:115)	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

~~~ 1606389857381.stacktrace ~~~

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()	at android.os.Handler.<init>(Handler.java:200)	at android.os.Handler.<init>(Handler.java:114)	at android.widget.ViewFlipper$2.<init>(ViewFlipper.java:214)	at android.widget.ViewFlipper.<init>(ViewFlipper.java:214)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:73)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:63)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:62)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.createTabViewFor(MediaInputManager.kt:182)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.access$createTabViewFor(MediaInputManager.kt:50)	at dev.patrickgold.florisboard.ime.media.MediaInputManager$onRegisterInputView$1.invokeSuspend(MediaInputManager.kt:115)	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

~~~ 1606389874863.stacktrace ~~~

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()	at android.os.Handler.<init>(Handler.java:200)	at android.os.Handler.<init>(Handler.java:114)	at android.widget.ViewFlipper$2.<init>(ViewFlipper.java:214)	at android.widget.ViewFlipper.<init>(ViewFlipper.java:214)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:73)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:63)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:62)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.createTabViewFor(MediaInputManager.kt:182)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.access$createTabViewFor(MediaInputManager.kt:50)	at dev.patrickgold.florisboard.ime.media.MediaInputManager$onRegisterInputView$1.invokeSuspend(MediaInputManager.kt:115)	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

~~~ 1606389877772.stacktrace ~~~

java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()	at android.os.Handler.<init>(Handler.java:200)	at android.os.Handler.<init>(Handler.java:114)	at android.widget.ViewFlipper$2.<init>(ViewFlipper.java:214)	at android.widget.ViewFlipper.<init>(ViewFlipper.java:214)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:73)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:63)	at dev.patrickgold.florisboard.ime.media.emoji.EmojiKeyboardView.<init>(EmojiKeyboardView.kt:62)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.createTabViewFor(MediaInputManager.kt:182)	at dev.patrickgold.florisboard.ime.media.MediaInputManager.access$createTabViewFor(MediaInputManager.kt:50)	at dev.patrickgold.florisboard.ime.media.MediaInputManager$onRegisterInputView$1.invokeSuspend(MediaInputManager.kt:115)	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

Do note this is an old phone that I plan on changing soon as I said earlier, this is a very old Android version.
I guess it'd still be nice to fix that for people still running old phones like me ^^'

Thanks for the awesome work (even if i can't try it yet) !

[patrickgold]

Hey Lurux,

thanks for sending the stacktraces and the positive feedback :)

I haven't been in Android Studio yet but based on the output it seems that it crashes somewhere while building the emoji UI. I will investigate this and push a fix commit later.

One question: Just out of interest, you've written that you are on a very old Android version, would you mind sharing which one?

[Lurux]

Hey Lurux,

Thanks for sending the stacktraces and the positive feedback :)

I haven't been in Android Studio yet but based on the output it seems that it crashes somewhere while building the emoji UI. I will investigate this and push a fix commit later.

Yeah, I've seen that indeed. I don't really know how Android works, but wouldn't it be a good idea to not build the emoji UI until the actual button is pressed ? It would save time when opening the keyboard 😃

One question: Just out of interest, you've written that you are on a very old Android version, would you mind sharing which one?

6.0, I'm pretty I wrote that in the OP.

Just a note, many emojis are glitched in openboard for me. I think this is linked to the old Android version. So depending on the way your emoji board is implemented, this may or may not be cleanly fixable in this case.

Just a question by the way, is this keyboard based on something else or completely written from scratch ? I haven't seen anything mentioning this in the readme. 🤔

[patrickgold]

Yeah, I've seen that indeed. I don't really know how Android works, but wouldn't it be a good idea to not build the emoji UI until the actual button is pressed ? It would save time when opening the keyboard 😃

The media UI is created asynchronously to main UI, so it doesn't really affect startup performance. I actually had the mechanic of creating the media UI only when pressing on the emoji button, but abandoned it because it has a second long lag at the first time and the UX of that isn't great.

6.0, I'm pretty I wrote that in the OP.

Welp this is awkward. But still thanks!

Just a note, many emojis are glitched in openboard for me. I think this is linked to the old Android version. So depending on the way your emoji board is implemented, this may or may not be cleanly fixable in this case.

No, as far as I have seen the crash is because I'm interacting with the UI from a non-main thread where Android can get pretty upset about and just crashes your app. I'm not particularly sure why it only happens on your device but it doesn't have something to to with the glitchiness. (It only affects the rendering, and at most you have weird emojis in the media UI, but not a crash).

Just a question by the way, is this keyboard based on something else or completely written from scratch ? I haven't seen anything mentioning this in the readme. 🤔

Nope, this keyboard has been written from scratch. (If you look at the very first commits you see the early and super-ugly tries of me understanding how an InputMethodService works in Android 😄 ).

Only a few concepts in how to align the keyboard in the window have been inspired by the AOSP LatinIME (e.g. ViewLayoutUtils.kt), because I would have never been able to do that without looking at their implementation. Also some parts of my crash handler are inspired by the CAOC library. Note, that I've added document comments within those source files to mark that my code has been inspired by these, alongside with the license and a reference to the corresponding original file. Some functions also have links to StackOverflow questions, so everyone can follow along where I got this exact implementation for a specific method.

Everything else, especially the keyboard layout implementation has been made from scratch. Basically every other open-source keyboard relies on the default KeyboardView class + xml layouts, mine is a custom implementation and works with json layout files.

Feel free to ask me anything if you are interested further!

[Lurux]

6.0, I'm pretty I wrote that in the OP.

Welp this is awkward. But still thanks!

Why awkward ?

Just a question by the way, is this keyboard based on something else or completely written from scratch ? I haven't seen anything mentioning this in the readme. thinking

Nope, this keyboard has been written from scratch. (...)

I'm really curious, what was your main reason to write everything from scratch ? 🤔

Btw, please tell me when the bug is fixed, I can't wait to give this a try ! 😃

[patrickgold]

Why awkward ?

Awkward because you wrote your Android version in the original comment and I haven't checked it before asking...

I'm really curious, what was your main reason to write everything from scratch ? 🤔

Mainly because all popular open-source keyboards are based on the default KeyboardView implementation, which is officially deprecated since Android 10 (but still fully working even in Android 11). If Google ever decides to remove this class in a future Android release, I'm prepped for this and FlorisBoard will fully work without having to rewrite the core. Also I wasn't a fan of how the xml keyboard layouts are defined, with my custom implementation I have full control over how the json layout file should look like.

Btw, please tell me when the bug is fixed, I can't wait to give this a try ! 😃

Will do as soon as I push a fix commit! 😄

[patrickgold]

Above commit fixes the initialization of EmojiKeyboardView, allowing FlorisBoard to fully work on Android 6.0 devices. Will be included in the next release v0.2.5, which will be released tomorrow evening.

[Lurux]

I'm really curious, what was your main reason to write everything from scratch ? thinking

Mainly because all popular open-source keyboards are based on the default KeyboardView implementation, which is officially deprecated since Android 10 (...)

Wait, isn't this what the AOSP keyboard is still using ? I would assume most open-source keyboards are based on that, and I doubt KeyboardView would be removed before AOSP stops using it...

Above commit fixes the initialization of EmojiKeyboardView, allowing FlorisBoard to fully work on Android 6.0 devices. Will be included in the next release v0.2.5, which will be released tomorrow evening.

Is it normal the milestone you set is for 0.3 ? Anyway, I see the release is not here yet, I'll try it out when it comes out !

[patrickgold]

Wait, isn't this what the AOSP keyboard is still using ? I would assume most open-source keyboards are based on that, and I doubt KeyboardView would be removed before AOSP stops using it...

Yeah that's a good point but still from a programmer's perspective I like my approach more and I have a way more granular control over how the KeyboardView works, so I'm going with the custom implementation.

Is it normal the milestone you set is for 0.3 ? Anyway, I see the release is not here yet, I'll try it out when it comes out !

Yes because I want this feature to be ready not later then v0.3.0. To decrease waiting times on new features and fixes I do releases like v0.2.5 to get them faster to the end user.

[Lurux]

Wait, isn't this what the AOSP keyboard is still using ? I would assume most open-source keyboards are based on that, and I doubt KeyboardView would be removed before AOSP stops using it...

Yeah that's a good point but still from a programmer's perspective I like my approach more and I have a way more granular control over how the KeyboardView works, so I'm going with the custom implementation.

I would agree diversity is important anyway, I was just being curious 😉

Is it normal the milestone you set is for 0.3 ? Anyway, I see the release is not here yet, I'll try it out when it comes out !

Yes because I want this feature to be ready not later then v0.3.0. To decrease waiting times on new features and fixes I do releases like v0.2.5 to get them faster to the end user.

Ah okay, that makes sense.