Introduction

On Android, imeOptions controls what action button the soft keyboard shows, but it does not by itself implement the behavior behind that button. If you want to react to the Done action, the normal solution is to set the input field's IME option and then listen for the corresponding editor action in code. The important distinction is that the XML changes keyboard presentation, while the listener handles application behavior.

Set the IME Action on the Input Field

Start by telling the EditText that it should present a Done-style action.

1<EditText
2    android:id="@+id/nameInput"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:hint="Enter your name"
6    android:inputType="text"
7    android:imeOptions="actionDone" />

That affects the keyboard's action button label and intent, but it does not automatically submit a form, hide the keyboard, or move focus. You still have to define what “done” means on this screen.

Handle the Action in Kotlin

The common pattern is setOnEditorActionListener combined with a check for EditorInfo.IME_ACTION_DONE.

1import android.os.Bundle
2import android.view.inputmethod.EditorInfo
3import android.widget.EditText
4import android.widget.Toast
5import androidx.appcompat.app.AppCompatActivity
6
7class MainActivity : AppCompatActivity() {
8    override fun onCreate(savedInstanceState: Bundle?) {
9        super.onCreate(savedInstanceState)
10        setContentView(R.layout.activity_main)
11
12        val input = findViewById<EditText>(R.id.nameInput)
13
14        input.setOnEditorActionListener { _, actionId, _ ->
15            if (actionId == EditorInfo.IME_ACTION_DONE) {
16                Toast.makeText(this, "Done pressed", Toast.LENGTH_SHORT).show()
17                true
18            } else {
19                false
20            }
21        }
22    }
23}

Returning true tells Android that your code handled the event. Returning false lets the framework or keyboard continue default handling.

Hide the Keyboard and Clear Focus

Many screens want the Done action to conclude editing cleanly. That usually means hiding the keyboard and removing focus from the field.

1import android.content.Context
2import android.view.inputmethod.EditorInfo
3import android.view.inputmethod.InputMethodManager
4import android.widget.EditText
5
6fun setupDoneAction(input: EditText) {
7    input.setOnEditorActionListener { view, actionId, _ ->
8        if (actionId == EditorInfo.IME_ACTION_DONE) {
9            val imm = view.context.getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager
10            imm.hideSoftInputFromWindow(view.windowToken, 0)
11            view.clearFocus()
12            true
13        } else {
14            false
15        }
16    }
17}

Without those follow-up steps, the UI may technically handle the action but still feel unfinished to the user.

Some Keyboards Send Enter-Key Events Too

Different keyboard apps do not always behave identically. In some cases you may also receive a KeyEvent for the Enter key. If you need more defensive handling, check both paths.

1import android.view.KeyEvent
2import android.view.inputmethod.EditorInfo
3
4input.setOnEditorActionListener { _, actionId, event ->
5    val isDoneAction = actionId == EditorInfo.IME_ACTION_DONE
6    val isEnterKey = event?.keyCode == KeyEvent.KEYCODE_ENTER && event.action == KeyEvent.ACTION_DOWN
7
8    if (isDoneAction || isEnterKey) {
9        println("Input finished")
10        true
11    } else {
12        false
13    }
14}

You do not always need this extra check, but it is useful when behavior varies across devices or keyboards.

Decide What Done Means on This Screen

The listener should not just detect a button press. It should map the keyboard action to the screen's intent.

Common meanings include:

• submit a login form
• validate the current field
• hide the keyboard after editing
• trigger a search or filter action
• move the workflow to the next screen state

Being explicit about that meaning makes the code much easier to maintain than scattering small keyboard handlers with no clear UI contract.

Keep the Listener Close to the UI Logic

It is tempting to put IME handling into a generic helper immediately, but the behavior often belongs to the specific screen. A login screen may submit. A comment box may insert the final content. A settings field may just hide the keyboard.

Reusable helpers are good for mechanical tasks such as keyboard dismissal, but the business action behind Done should usually stay near the screen code that owns the input.

Common Pitfalls

• Setting android:imeOptions="actionDone" and expecting it to handle the button press automatically.
• Returning false even though the app already handled the action, which can lead to duplicate behavior.
• Ignoring device or keyboard variations where an Enter key event appears alongside or instead of the editor action.
• Hiding the keyboard without clearing focus, which leaves the field in an awkward half-active state.
• Treating Done as a visual label only instead of mapping it to a specific screen-level action.

Summary

• 'imeOptions changes the keyboard action button, but behavior is implemented in code.'
• Use setOnEditorActionListener and check for EditorInfo.IME_ACTION_DONE.
• Return true when your code consumes the event.
• Hiding the keyboard and clearing focus are common follow-up steps.
• The right handler depends on what “done” actually means in that specific UI flow.