Gboard keyboard can not be used properly in termux

[torappinfo]

Problem description
when gboard input method is used with termux, only ascii keyboard can be used.

Steps to reproduce
Install google gboard keyboard, and use it with termux

Expected behavior

Additional information
never worked with any version of termux

• Termux application version:
• Android OS version:
• Device model:

[trygveaa]

It works fine for me (and has always worked fine). You need to provide more details.

I use the Norwegian layout in Gboard, which has the non-ascii characters æ, ø and å and they work.

[debugrr]

I also have no issues with Gboard.
Is it a particular language?

do you have similar issues with any other keyboard?

Any character examples? or screenshots?

[snogglethorpe]

At least for me, Termux forces Gboard into QWERTY mode, and won't let you switch to another language. To input other languages, you need to use Termux's "text input view" (swipe left on the function key bar); in that mode, all Gboard languages work. This really isn't very difficult, but maybe it's not so obvious to new users...

[trygveaa]

I can switch to other languages/layouts by long pressing the space bar, no matter if the text input view is active or not. It's not forced to qwerty either.

[snogglethorpe]

I can switch to other languages/layouts by long pressing the space bar, no matter if the text input view is active or not. It's not forced to qwerty either.

I wonder if this is Android-version specific.... I'm on Android 7.0.

[trygveaa]

Could be. I'm on Android 10 on a Pixel 3.

[atharvadnaik]

My problem solved when I switched to different keyboard which doesn't have features like autocorrect, autocomplete or predictive text...You can try turning off predictive text

[Yisus7u7]

Simply turn off automatic remediation and autocomplete, or use another keyboard as keyboard hackers

[YanceyChiew]

My experience is the same, and turning off spell check and input prediction will not help.

Changing the input method can certainly work, but the premise is that the design of the input method itself does not meet the specifications.

Termux's code is programmed to use a char-based keyboard for regular input, to ensure this, termux added an property in its configuration file(~/.termux/termux.properties), namely enforce-char-based-input.

This property is not true by default, because termux believes that the correctly implemented input method has same effects when using input.TYPE_NUL, just like gboard. Only when necessary, set its value to true, those other input methods with different behaviors of input.TYPE_NUL will become like gboard and only display the visible password keyboard.

Obviously, the visible password keyboard or none(default) keyboard in gboard both will not display any extra buttons, such as settings, clipboard, character selection, etc. This does bring some inconvenience, at least, for me. Using two-line shortcut keys and pre-input text box to make up for the lack of password keyboard is a solution.

termux-app/terminal-view/src/main/java/com/termux/view/TerminalView.java

Line 269 in d736b1e

outAttrs.inputType = InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS;

[ghost]

@YanceyChiew When using gboard, the input type set as

outAttrs.inputType = InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS; 

may cause keyboard to overlap the extra keys row on some configurations.

Before:

After:

In case of disabled extra keys, it will overlap few lines of command prompt.

[agnostic-apollo]

may cause keyboard to overlap the extra keys row on some configurations.

Seems like a bug in the rom, android handles pushing up the view itself. It's done by WindowManager.LayoutParams.SOFT_INPUT_ADJUST_RESIZE flag which is set by Termux. Although, the flag is deprecated in API 30, but it still should work properly, maybe using WindowInset API fixes the issue. What's the android version? Working fine on my LG G5 Android 7.0, also language switching works.

[ghost]

What's the android version?

Android 11 from Pixel 5.

[agnostic-apollo]

Thanks. Will look into in future. Working fine on pixel 3a android 11 avd though.

[ghost]

@agnostic-apollo Do you have the latest gboard installed and clipboard suggestions enabled?

[agnostic-apollo]

Well, I was on the preinstalled version 9.4.11.312687073-preload-x86, but I updated to latest version 10.5.03.367007960-release-x86. I did enable clipboard suggestions but working fine still, but that shouldn't affect hiding of extra keys since suggestions don't show in terminal view, with and without ctrl-space-workaround enabled. That's only for input text view, in which extra keys don't show anyways. And "few lines of command prompt" are also not overlapped if extra keys are disabled.

[RalfWerner]

I have the same behavior on my Android 9 Gigaset (same Gboard version like @xeffyr but armv7). The one Extra Key line (shot1) contains Ctrl (^) and KEYBOARD-toggle. After Copy the selected text is displayed over the Extra Key line (shot2). Toggling is no longer possible only after back key (shot3). However, the line remains after again "On-Toggle".
The CRTL+Space workaround does not work because ^ is hidden. But there are other workarounds such as Hacker/Gboard toggle. Paste removes the clipboard info but not the line. In the gboard settings I have found no clipboard line=off or similar. But possibly have you @agnostic-apollo more success (I prefer Clipboard in mind instaed on screen).

With most of your last changes, I am very satisfied, except for a few workarounds that remained ff. In the meantime, the "Discord kids" have also discovered "T: X11" and are increasingly changing from VNC to this Xserver. Therefore again the request about common Extra Keys.

[agnostic-apollo]

So I did some more testing. On Android 11 avd, the clipboard suggestion bar don't show when text is copied with ctrl-space-workaround=true and its setting enabled in gboard setttings. It does show on Android 7 LG G5.

This seems like an OS bug to me, android is responsible for pushing up the view depending on keyboard height. In my logcat, when clipboard suggestions bar is showing or not, for both cases, the following entries exist, when keyboard is opened

I/KeyboardViewUtil: KeyboardViewUtil.getKeyboardHeightRatio():166 systemKeyboardHeightRatio:1.000000; userKeyboardHeightRatio:1.000000.
I/KeyboardViewUtil: KeyboardViewUtil.calculateMaxKeyboardBodyHeight():62 leave 500 height for app when screen height:2392, header height:176 and isFullscreenMode:false, so the max keyboard body height is:1716
I/KeyboardViewUtil: KeyboardViewUtil.calculateMaxKeyboardBodyHeight():62 leave 500 height for app when screen height:2392, header height:176 and isFullscreenMode:false, so the max keyboard body height is:1716
I/NormalModeController: NormalModeController.getKeyboardBodyViewHolderPaddingBottom():114 currentPrimeKeyboardType:SOFT systemPaddingBottom:-1
I/NormalModeController: NormalModeController.getKeyboardBodyViewHolderPaddingBottom():114 currentPrimeKeyboardType:SOFT systemPaddingBottom:-1

So android itself is not detecting that gboard suggestions bar is showing.

Edit:
The insets.getInsets(Type.ime()).bottom value doesn't change either.

Edit2:
The above logcat entries are from Gboard, not android os.

Someone emailed similar case for SwiftKey where number row was covering terminal.

There is a similar report about this here, but extra keys work differently.

The hack that I can think of to make this work could to be to allow user to add terminal-bottom-margin to termux.properties which will be used to always show some space below extra keys and terminal. I guess a key could be added to extra keys to toggle this, so that user for whom this only happens when copying text can do it temporarily while gboard shows the suggestion, and toggle it again when it doesn't. I currently hardcoded this by adding android:layout_marginBottom="40dp" to root RelativeLayout of activity_termux.xml, but this should be configurable dynamically. Maybe there is a better way, android views are not my thing.

[RalfWerner]

So I did some more testing. On Android 11 avd, the clipboard suggestion bar don't show when text is copied

Dit you do version 10.5.03.367007960-release-x86` update?
I did it here on a Pixel-4 AVD with Android 10 and then get the overlapping extra row (after Copy above):

After Paste, BACK and KEYBOARD key I get:

Before of Paste I have replaced clipboard with an alternative text. The workaround has corrected (remove extra line) this again. However, sometimes I get google Restarts or KEYBOARD must press several times.
The clipboard text in the extra line is sometimes changed and sometimes not. The property: enforce-char-based-input=false does not change the behavior. The option "Turn off the Extra line without replacement" (hold in mind) would like me.

[agnostic-apollo]

So Gboard issue should be fixed with e7dd0ee. I have tested it on android 7 device and android 10 and 11 avd. For android 11 avd, I had to clear Gboard's app data for new UI to load properly. Moreover, for bug to occur, you also need to enable number keys row toggle to be enabled in gboard settings in addition to clipboard suggestions toggle.

I am not sure if this will fix issues with other keyboards, but hopefully should do it since solution used is kinda generic and will work with and without enforce-char-based-input enabled. If this causes some problems, like infinite loop or something of margin adjustments, let me know. Redraws of terminal view are expected in some cases. Check TermuxActivityRootView javadocs for the details. It also clears some inaccuracies in my above comment.

New release is planned to be released today if no bugs come in.

[RalfWerner]

Thanks! I've checked on my Pixel_2_API_30.avd. Complete reset was needet (stalled 2 h work/wait) and gboard update. I get:

Aditional to this (arch=i686) I've installed on my Gigaset (arch=arm) and get:

On both devices your last master update (version 114 I've extendet) are installed and the boot-loop update was done. I continue with OS-KB check. The gboard bug is solved and this issue could be closed!

[agnostic-apollo]

Thanks for the confirmation. Would be good to have swiftkey number rows solved as well.

The gboard bug is solved and this issue could be closed!

This issue is not related to overlap issue. Overlap is (also) reported in #538

[RalfWerner]

Would be good to have swiftkey number rows solved as well.

If above the extra key line is missing, the problem is already solved in v113. In the following shot (horizontal split), next to the Swift-KB, Termux (left) with the Extra Key line and X11 (right) _with its Extra Keys (not in vertical position) can be seen - without overlaps.

[agnostic-apollo]

It could also be a device specific issue so not sure yet. And e7dd0ee should work even if extra keys are enabled or not.

[lctx]

This bug appears me after type "apt upgrade" using the app from Google Play(is not the last version), so I uninstall it and install the Fdroid version 0.117 but the bug still persist.
I solve this changing the idiom of gboard from multilingual(English / Spanish) to Spanish or English.
I'm using a Redmi C3 and use Android 11.

[agnostic-apollo]

So I managed to reproduce the issue too. It doesn't happen in all multilingual languages including Norwegian.

It does happen with Chinese Traditional language, when you open termux with it selected, the keyboard space bars literally says QWERTY instead of the Chinese language symbols. The value for enforce-char-based-input does not affect this, so I wonder how chinese people type passwords in chinese if gboard switches to QWERTY mode with InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS. The value for Suggest English words which would likely be equivalent to Multilingual typing toggle for some other languages does not affect it either. I only tested on Android 7 though.

Also found a termux bug where if in text input view mode and chinese was showing properly and I switch to another app and come back to termux which would still start in text input view mode, the QWERTY keyboard was loaded. That should be fixed by 2b7aa5e.

As for fixing the forced QWERTY issue, that seems to be an issue with Gboard and not termux, although chinese does show with InputType.TYPE_TEXT_VARIATION_URI but that has the issue of characters not showing until space is pressed. It should be reported to Gboard support for fixing since we need correct behaviour with InputType.TYPE_NULL.