Automatic popping up keyboard on start Activity

Question

I got a relative simple question. I have an activity with a lot of EditText's in them. When I open the activity it automatically focusses to the first EditText and displays the virtual keyboard.

How can I prevent this?

Answer 1

I have found this simple solution that worked for me.Set these attributes in your parent layout:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/mainLayout"
android:descendantFocusability="beforeDescendants"
android:focusableInTouchMode="true" >

And now, when the activity starts this main layout will get focus by default.

Also, we can remove focus from child views at runtime by giving the focus to the main layout again, like this:

findViewById(R.id.mainLayout).requestFocus();

Hope it will work for you .

Answer 2

Use this attributes in your layout tag in XML file:

android:focusable="true"
android:focusableInTouchMode="true"

As reported by other members in comments it doesn't works on ScrollView therefore you need to add these attributes to the main child of ScrollView.

Answer 3

If you have another view on your activity like a ListView, you can also do:

ListView.requestFocus(); 

in your onResume() to grab focus from the editText.

I know this question has been answered but just providing an alternative solution that worked for me :)

Answer 4

((InputMethodManager)getActivity().getSystemService("input_method")).hideSoftInputFromWindow(this.edittxt.getWindowToken(), 0);

Answer 5

I had a simular problem, even when switching tabs the keyboard popped up automatically and stayed up, with Android 3.2.1 on a Tablet. Use the following method:

public void setEditTextFocus(EditText searchEditText, boolean isFocused)
{
    searchEditText.setCursorVisible(isFocused);
    searchEditText.setFocusable(isFocused);
    searchEditText.setFocusableInTouchMode(isFocused);
    if (isFocused) {
        searchEditText.requestFocus();
    } else {
        InputMethodManager inputManager = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE); 
        inputManager.hideSoftInputFromWindow(searchEditText.getWindowToken(), InputMethodManager.HIDE_NOT_ALWAYS );
    }
}   

In the onCreate() and in the onPause() of the activity for each EditText:

setEditTextFocus(myEditText, false);

For each EditText an OnTouchListener:

    myEditText.setOnTouchListener(new EditText.OnTouchListener() {
        @Override
        public boolean onTouch(View v, MotionEvent event) {
            setEditTextFocus(myEditText, true); 
            return false;
        }
    });

For each EditText in the OnEditorActionListener:

    myEditText.setOnEditorActionListener(new EditText.OnEditorActionListener() {
        @Override
        public boolean onEditorAction(TextView arg0, int arg1, KeyEvent arg2) {
                            .......
            setEditTextFocus(myEditText, false); 
            return false;
        }
    });

And for each EditText in the layout xml:

            android:imeOptions="actionDone"
            android:inputType="numberDecimal|numberSigned" // Or something else

There is probably more code optimizing possible.

Answer 6

This has some good answers at the following post : Stop EditText from gaining focus at Activity startup. The one I regularly use is the following code by Morgan :

<!-- Dummy item to prevent AutoCompleteTextView from receiving focus -->
<LinearLayout
    android:focusable="true" 
    android:focusableInTouchMode="true"
    android:layout_width="0px" 
    android:layout_height="0px"/>

<!-- :nextFocusUp and :nextFocusLeft have been set to the id of this component
to prevent the dummy from receiving focus again -->
<AutoCompleteTextView android:id="@+id/autotext"
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content"
    android:nextFocusUp="@id/autotext"     
    android:nextFocusLeft="@id/autotext"/>

NOTE : The dummy item has to be PLACED RIGHT BEFORE the focusable element.

And I think it should work perfectly even with ScrollView and haven't had any problems with accessibility either for this.