Introduction

On Android, the soft keyboard appears automatically when an input view has focus as an activity starts. This can hurt first-screen experience on dashboards, detail pages, and read-only flows. Preventing it reliably usually requires manifest configuration plus explicit focus policy. It is best handled as a screen-design decision, not a one-off workaround.

Configure windowSoftInputMode

The first control point is activity configuration in AndroidManifest.xml.

<activity
    android:name=".MainActivity"
    android:windowSoftInputMode="stateHidden|adjustResize" />

stateHidden requests that keyboard remains hidden on launch. adjustResize helps layout behave correctly once keyboard appears later.

If theme also sets soft input mode, confirm activity and theme values are not conflicting.

Avoid Initial Focus on EditText

Even with stateHidden, focused input fields can still trigger keyboard on some devices. Set root view as focusable and remove default focus from inputs.

1<LinearLayout
2    android:id="@+id/root"
3    android:layout_width="match_parent"
4    android:layout_height="match_parent"
5    android:orientation="vertical"
6    android:focusable="true"
7    android:focusableInTouchMode="true">
8
9    <EditText
10        android:id="@+id/searchInput"
11        android:layout_width="match_parent"
12        android:layout_height="wrap_content"
13        android:hint="Search" />
14</LinearLayout>

Then request focus on the root in code during startup.

val root = findViewById<View>(R.id.root)
root.requestFocus()

Programmatic Hide as Backup

When navigation or lifecycle timing still causes keyboard display, hide it in onCreate or onResume as a fallback.

1import android.view.inputmethod.InputMethodManager
2import androidx.core.content.getSystemService
3
4fun hideKeyboard(activity: Activity) {
5    val imm = activity.getSystemService<InputMethodManager>() ?: return
6    val token = activity.currentFocus?.windowToken ?: activity.window.decorView.windowToken
7    imm.hideSoftInputFromWindow(token, 0)
8}

Use this sparingly. Overuse can fight normal UX when users expect immediate input.

Fragment Navigation Considerations

If your app uses fragments, keyboard behavior may differ by destination. Keep focus policy at fragment level where input actually lives.

For example:

• Read-only fragment: clear focus in onViewCreated.
• Edit fragment: request focus and show keyboard intentionally.

This avoids one global activity rule that breaks specific screens.

UX Rules for When Not to Hide

Do not force keyboard hidden on screens where typing is the first action, such as:

• Search-first pages.
• Login pages where username field is the main entry point.
• Chat composer screens.

In those contexts, automatic keyboard display improves usability. The objective is intentional behavior, not always hidden behavior.

Testing Across Devices

Keyboard behavior varies by Android version and OEM keyboard implementation. Test:

1. Cold app launch.
2. Returning via back stack.
3. Rotation changes.
4. Split-screen mode.
5. Hardware keyboard connected.

A minimal debug check:

adb logcat | rg InputMethod

This helps diagnose unexpected show and hide events.

Jetpack Compose Note

If your screen uses Compose, keyboard visibility is still driven by focus state. Avoid requesting focus automatically in first composition unless text entry is the primary task.

val focusRequester = FocusRequester()
// Request focus only after explicit user action, not on initial load

Compose and View-based screens can coexist in one app, so keep keyboard policy consistent across both stacks to avoid confusing user transitions.

Common Pitfalls

• Setting windowSoftInputMode but leaving EditText focused at startup.
• Combining theme and activity soft-input flags with conflicting values.
• Hiding keyboard globally even on screens that need immediate typing.
• Applying fix only at activity level while fragment focus logic overrides it.
• Testing on one device and assuming behavior is identical everywhere.

Summary

• Use windowSoftInputMode as the primary keyboard-start behavior control.
• Remove initial focus from input fields when keyboard should stay hidden.
• Apply programmatic hide only as fallback for edge timing cases.
• Keep focus strategy aligned with per-screen UX intent.
• Validate behavior across device types and navigation flows.