Introduction

Showing or hiding the Android soft keyboard programmatically is mostly about timing and focus. The keyboard is controlled by the input method system, so the view must usually have focus and be attached to a window before a show request behaves reliably.

Show the Keyboard for a Focused View

The classic API uses InputMethodManager. The target view should already be focusable and should request focus first.

1import android.content.Context
2import android.view.inputmethod.InputMethodManager
3import android.widget.EditText
4
5fun showKeyboard(editText: EditText) {
6    editText.requestFocus()
7    editText.post {
8        val imm = editText.context.getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager
9        imm.showSoftInput(editText, InputMethodManager.SHOW_IMPLICIT)
10    }
11}

The post call matters because it delays the request until the view is attached and the UI thread has completed the current layout work. Without that, a show request can be ignored.

Hide the Keyboard With the Window Token

To hide the keyboard, use the view's window token.

1import android.content.Context
2import android.view.View
3import android.view.inputmethod.InputMethodManager
4
5fun hideKeyboard(view: View) {
6    val imm = view.context.getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager
7    imm.hideSoftInputFromWindow(view.windowToken, 0)
8}

This is the usual answer when the user taps a button, submits a form, or navigates away from text input.

Activity Example

A simple activity pattern looks like this:

1class MainActivity : AppCompatActivity() {
2    override fun onCreate(savedInstanceState: Bundle?) {
3        super.onCreate(savedInstanceState)
4        setContentView(R.layout.activity_main)
5
6        val input = findViewById<EditText>(R.id.input)
7        val done = findViewById<Button>(R.id.doneButton)
8
9        showKeyboard(input)
10
11        done.setOnClickListener {
12            hideKeyboard(input)
13        }
14    }
15}

The important detail is that keyboard behavior is tied to the currently focused window and view. If the wrong view owns focus, keyboard commands may not do what you expect.

Why Keyboard Calls Often Seem Inconsistent

Developers often assume the API is unreliable, but the underlying problem is usually one of these:

• The target view does not have focus.
• The view is not attached yet.
• The wrong window token is used.
• A navigation transition changes focus right after the request.

In other words, the timing and focus model usually explain the inconsistency.

Modern API Surface Still Follows the Same Rules

Newer Android APIs and compatibility helpers can improve ergonomics, but the basic rule does not change: the IME responds to the focused window and view state. Even when you use newer insets-oriented helpers, focus and timing are still the real prerequisites.

So if show or hide calls fail, debug the lifecycle and focus chain before assuming the keyboard service is broken.

When Not to Force the Keyboard

Programmatic keyboard control should support the interaction, not fight it. If the user did not navigate into an input-focused flow, forcing the keyboard open can feel jarring and can even race with navigation or window transitions.

Dialogs and fragments add another layer of timing, so test keyboard behavior in the exact container where the input lives.

Common Pitfalls

• Calling showSoftInput before the target view is attached to the window.
• Forgetting to request focus on the EditText before showing the keyboard.
• Hiding the keyboard with a stale or unrelated window token.
• Forcing keyboard visibility too aggressively and creating a poor user experience.
• Debugging only the keyboard call instead of checking focus and lifecycle timing.

Summary

• Keyboard control on Android depends heavily on focus and timing.
• Show the keyboard only after the input view has focus and is attached.
• Hide the keyboard using the target view's window token.
• 'post is often enough to make a show request reliable.'
• Most keyboard bugs are really focus or lifecycle bugs rather than API bugs.