Develop Reference

android - edittext keyboard not showing

I am creating an edittext programmatically. But I was not able to type anything into the edittext. I have covered all the related answers on this site but none of them worked for me. Maybe I am missing some minor details. It would be helpful if I can get some help.
Code to create edittext dynamically:
EditText editText = new EditText(dt.c);
editText.setBackground(context.getResources().getDrawable(R.drawable.rectangle_answer));
editText.setTextColor(ContextCompat.getColor(dt.c, R.color.md_black_1000));
editText.setTextSize(16);
editText.setTag(questionDetails[0].getOptionId());
editText.setFocusable(true);
editText.setHint(dt.gStr(R.string.enter_your_answer));
editText.requestFocus();
container.Add(editText);
Some of the answers that I covered:
How can I set the focus (and display the keyboard) on my EditText programmatically
Android - EditText made programmatically not showing keyboard
Android: How to open keyboard for editing EditText when click button?
Disable keyboard on EditText
How to disable the keyboard when I click on EditText?

I was having the same problem and nothing worked until I found an answer way down in one of the posts from years ago that worked. I'll repost the weird hack for anyone who might have this problem in the future.
In your xml file, add a dummy edittext to your topmost layout layer that looks like this:
<EditText
android:id="#+id/editTextFix"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:importantForAutofill="no"
tools:targetApi="o"
android:inputType="text"
android:visibility="gone"/>
the dummy edittext will open the keyboard, but your programatically created edittext will still have focus.

Stop EditText from bringing up the keyboard on Activity start?

I have an Edit Text in one of my App layouts, and I want this EditText to only open the keyboard (I believe this is called being focused on?) when it is actually touched.
As of now, the keyboard opens with the EditText whenever the app opens, which isn't what I want.
I have tried many different XML tags to fix this:
android:focusable="false" <--- Prevents keyboard from opening at all.
android:focusable="true"
android:focusableInTouchMode = "true" <--- These tags give me the same result as no tags (keybaord will open on activity start)
android:focusedByDefault = "true" <--- Only available in API >= 23
What I am asking is, why is it so hard to disable default focus on an EditText? Surely I am missing an easy way to do this.
EDIT: Adding this line to my AndroidManifest fixed the issue:
android:windowSoftInputMode="stateHidden"
However, I don't like this solution. It seems like since this is in the Manifest, it will affect more UI elements than the single EditText I need to change.

Alternatively you can set the focus to the root layout element:
android:focusable="true"
android:focusableInTouchMode="true"
Example:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:focusable="true"
android:focusableInTouchMode="true">
<EditText
android:inputType="text"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
</LinearLayout>

Use android:windowSoftInputMode="stateHidden"
If you dig deep into the Theme you are using for your Activity, you will find that the default value of windowSoftInputMode is stateUnspecified|adjustPan. And from the documentation:
stateUnspecified: Not specified, use what the system thinks is best. This is the default.
So depending on the the android device you run, your results will vary. I tried reproducing your case in API-26 emulator and the keyboard doesn't show up.You can use stateHidden to ensure that when an activity starts, the soft keyboard doesn't show up when the EditText gets focused on itself.
The other way to solve this is to requestFocus to some other element in the UI, making sure the EditText is not the first UI element to get focused. In my experience this is kind of a hack and it messes up the accessibility. The safest and clean way to accomplish is actually to use stateHidden.
stateHidden: Make the soft input area hidden when normally appropriate (when the user is navigating forward to your window).
Note that this will not affect any other UI elements. You can use adjustPan also to this, based on the screen background.

How to prevent soft keyboard from appearing on touch

I don't want the soft keyboard to appear when a particular EditText is touched. But I still want to be able to show the soft keyboard upon user request (say, when a button is pressed) and allow the user to edit the text.
I know how to show/hide the soft keyboard, I only don't know how to prevent it from appearing on touch.
Any suggestion how to do it?
The general idea is that the user will be mostly working with selection/position within the text, and only occasionaly entering characters.
I don't want the visible amount of text to be reduced by the soft keyboard when selecting or navigating the text.

simply use
txtEdit.setShowSoftInputOnFocus(false);
and when you want to enable that , reverse above process

This works:
editText.setShowSoftInputOnFocus(false);

within the activity in the manifest add the below code
android:windowSoftInputMode="adjustPan"

AndroidManifest.xml windowSoftInputMode
<activity android:name=".MyActivity" android:windowSoftInputMode="adjustPan"> </activity>

Try the below code, it hides the keyboard:
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN)

Why don't you disable the edittext. Then it will not show keyboard on click. To this you can:
android:editable="false" //from xml
et.setEnabled(false); //from activity
And then on your buttonClick make it enable by setting above code true. And make your keyboard appear.
Also If you don't get the focus on edittext you can:
et.requestFocus(); // from activity
<EditText
android:id="#+id/et1"
android:editable="false"
android:layout_width="150dp"
android:layout_height="wrap_content" >
<requestFocus/>
</EditText>
//from xml
Hope this helps!

Keyboard over EditText on second click

This is the picture:
When I click on the "Confirm password" EditText, for the first time, it works the way it should - layout pops up so I can enter text in selected EditText, but when I dismiss keyboard(that EditText still focused) and click on that same EditText again, it stays under keyboard.
Main layout is RelativeLayout, input fields are in ScrollView and buttons are in LinearLayout aligned to parent bottom.
In manifest I have android:windowSoftInputMode="adjustPan".
Is this some Android issue or I've been doing something wrong?

It's actually a bug in EditText. try removing gravity of EditText, which could be either center_horizontal or center
Got the answer from another question. check this.

For me removing android:minWidth does the trick

I just came with a workaround for this problem as well, I got my edit text to start the text in the middle of the screen with a not so great solution, but it works for me. The code is this one:
<EditText
android:layout_width="match_parent"
android:layout_height="0dp"
android:paddingStart="130sp"
android:paddingEnd="50sp"
android:descendantFocusability="beforeDescendants"
android:focusableInTouchMode="true"
android:gravity="bottom"/>

How to remove auto focus/keyboard popup of a field when the screen shows up?

I have a screen where the first field is an EditText, and it gains the focus at startup, also popups the numeric input type, which is very annoying
How can I make sure that when the activity is started the focus is not gained, and/or the input panel is not raised?

InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(editTextField.getWindowToken(), 0);
or
set activity property in manifest file as below in the application tag
android:windowSoftInputMode="stateHidden"

go to your application manifest file, and write this line for that activity you want to disable auto keyboard pop-up.
android:windowSoftInputMode="stateHidden"

To programatically not have the keyboard displayed, but the default widget still recieve focus call:
getWindow().setSoftInputMode(WindowManager.
LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
in onResume()

getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
call the above method inside onCreate().It prevent softKeyboard to show unless user select EditText by tapping or clicking.
or simply add android:windowSoftInputMode="stateHidden" in Activity tag in Manifest.xml

This is usually a mess. The first thing I try is try to steal the focus with another view via . You also have to have the focusable and focusableInTouchMode.
<TextView
...
android:focusable="true"
android:focusableInTouchMode="true">
<requestFocus/>
</TextView>

Have another view grab focus. By default, the first focusable View will get focus when a layout is inflated. You can request focus on a different View via XML:
<TextView
android:layout_width="wrap_parent"
android:layout_height="wrap_content"
android:text="Some other view">
<requestFocus />
</TextView>
This works for any View.
If you want to do it programmatically, you can use view.requestFocus().

Adding android:windowSoftInputMode="stateHidden" to your Activity in manifest only hides the keyboard when you are launching the activity, or as Google says
When the user affirmatively navigates forward to the activity, rather
than backs into it because of leaving another activity
To hide the keyboard also when user presses the back button and moves back to your activity from some other activity, use android:windowSoftInputMode="stateAlwaysHidden"

if(getWindow().getAttributes().softInputMode==WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED)
{
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN);
}

have not tried this nor am i near my programming computer, but I would suspect programmatically sending focus to the parent view or something of that nature could do the trick - thats more likely a workaround than a solution, but again not able to test it just a thought