Develop Reference

UI Automator with custom keyboard. Find exact keyboard button and click it

I'm trying to write UI automation tests for the custom soft keyboard using UI Automator and\or Espresso. Tried different ways but I can't find a proper solution to "find the exact button on the opened keyboard and click it".
Problems:
UIAtomator's UiDevice.findObject(By.text("Q")).click() doesn't find Q button on keyboard.
Espresso's onView(withText("Q")).perform(click()) doesn't find the button either.
For now, it looks like the only way to click button is to measure XY coordinates based on screen height and keyboard height. But this solution is ugly and not persistent.
typeText("text")and uiObject.text = "text" don't work since it bypasses keyboard input.
Was anyone working with custom keyboards? Please help.

Since you're building a custom soft keyboard then I expect you're using a KeyboardView. KeyboardView draws the keys using a canvas therefore it is not possible to get the resource ids of the keys... so no chance to find them through the UiDevice's findObject method.
Considering the KeyboardView class is deprecated since API 29, a possible solution will be to reimplement your own KeyboardView (as suggested here) and use AccessibilityNodeInfo class to build virtual elements (one for each key) that will be included into the view hierarchy.

The best solution in my opinion would be to create your own TCP server to solve this issue. Please refer to this link to find out how: https://ops.tips/blog/a-tcp-server-in-c/

qt/qml android virtual keyboard z pozition

I met the trouble with which I cant deal. I need to place the qml component (for example the Rectangle) above the native android soft keyboard. Is it real to do so?

I think you can't change z of keyboard, because keyboard and your application are different apps, but you can disable it. Because lack of code in your question, I can guess that you have TextFiled, you can set it to readonly property.
Also you can check state of the keyboard and hide it, when it shows, but I'd not recommended this method

A strange issue in Android O about typing using soft keyboard?

I tried my app in Android O and came up with a strange issue. I have a RecipientEditTextView which extends the AutoCompeteTextView, and after mismatch happens, the focus is still on the textview and cursor still flashing, however, the bottom buttons are pushed down and soft keyboard is still shown, when you try to type the soft keyboard, you just interact with the components beneath the keyboard. Since the code is quite complex I really cannot post code here. So my question is when can a soft keyboard be shown while cannot be typed.

This is a long standing bug. Keyboards are bound to views. You can get into a situation where the keyboard is bound to the wrong view. In that case, the typing will go to the view its bound to, and not to the one you expect. This is especially likely after a crash, you may see DeadObjectExceptions in the log.

Any way to "fix" android's assinine keyboard handling?

First of all, I am aware of about 1000 other questions regarding the android keyboard... I am aware I can manually hide keyboard from window or control, and pass in any number of flags that are supposed to control where and when keyboard pops up.
Basically, I aim to have PREDICTABLE keyboard handling in my app... that is that unless explicitly told to focus this control, and popup keyboard, it'll only pop up when a user taps a text edit.
This app is extensive, and manually attempting to hide keyboard from even just the focused control (vs explicitly hiding each and every edit field).
I am also aware I can avoid the popup up keyboard when you dont want it there, by setting focus on a non text editable field, however, that seems like more of a hack than anything else.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide? If I want this text field to et focus on new dialog, I'll manually handle those cases. In addition, any way to automatically handle keyboard dissapear when the previously focused control dissapears?
I just dont get logic there... if I step back and think about this, I'd only want keyboard popping up if I wanted to go type something. As far as keyboard popping up immediately when new dialog opens... seems like the exceptional case (there may be a couple times I'd want to do that).
I dont mind building a manager or something that keeps track of the state of keyboard, however i dont know if I can get at the information I'd need to make it work in a remotely intuitive manner, efficiently.
Any pointers or ideas would be greatly appreciated... because I am at my whits end with this... and I can assure you I've spent a good deal of time researching this and attempting fixes.
Note: Sorry about the title or hostility... I've fought this for quite some time, and been generally infuriated with how bizarre dealing with the keyboard can be.

So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide?
No.
But you can use:
this.getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
On each activity.

Ok, I think I get what you're asking. Have a look at the second answer here:
Stop EditText from gaining focus at Activity startup
You can specify in your AndroidManifest.xml whether or not the softkeyboard should be hidden by adding this android:windowSoftInputMode="stateHidden" to the beginning of your activities tag (<activity>)

How does an Android app load a keyboard?

I need to bring up a few different keyboards: a 'standard' keyboard with Ctrl and Alt keys; maybe a cursor pad; and so on.
I have found the Keyboard class, which would let me define a keyboard in an XML resource. I have found that the KeyboardView class has a setKeyboard method ... and, so far, I have not found any other class that takes a Keyboard instance.
How am I supposed to use the KeyboardView? I tried adding one to my activity's XML; finding it at runtime with findViewById; and then calling setKeyboard ... but all this did was mess up my layout and not bring up the special keyboard.

This turns out to be very doable, and my initial problems probably had more to do with general Android newbiness (this is my first Android app) and not the KeyboardView. In particular, I'm used to visibility being a simple binary property.
Anyhow:
Declare the KeyboardView in your XML file with android:visibility="gone".
Before you make the view visible, call setKeyboard() to attach a keyboard. This is important, as the KeyboardView gets its size from the keyboard.
To get raw key events, call KeyboardView.setOnKeyboardActionListener(). After refactoring this functionality from a Dialog back to my main View, I put the OnKeyboardActionListener functionality in a stand-alone class, but this is not necessary.
I call keyboardView.setEnabled(true);. This does not seem to be necessary, but I am not sure (yet) under what circumstances it would matter; perhaps only if you call setEnabled(false).
I call keyboardView.setPreviewEnabled(true); - this is especially useful if the user won't be getting visual feedback from an input biox right above the keyboard.
Then, with the keyboard all set, call keyboardView.setVisibility(VISIBLE);.
To hide the keyboard when appropriate, just call keyboardView.setVisibility(GONE);. To change the keyboard (as on a shift key, or a cycle-through-the-symbol-keyboards key, just call setKeyboard again. I use a Map<<Integer, Keyboard> to implement a lazy-create pattern; a weak reference may be desirable, if the program will run for a long time and the keyboard will not be used much.

Keyboard and KeyboardView are for making alternative input method engines (IME). These are then able to be chosen by the user, just as they can install Swype, Graffiti, and other ones from the Android Market.
You, as a developer, can create such an IME, but you cannot force it upon the user.

using the inputType attribute in your editText view will help pick between the different system keyboards (phone, email, etc) Also the APIDemos application that comes with the SDK has an example of how to implement a forced custom keyboard for your app only.