Introduction

Handling the backspace key in Android looks simple until soft keyboards, input methods, and empty fields start behaving differently than hardware keys. In practice, detecting "user pressed delete" depends on what you are trying to solve, because EditText does not guarantee that every deletion arrives as a plain key event.

Why OnKeyListener Is Not Always Enough

A common first attempt is attaching setOnKeyListener to an EditText and looking for KEYCODE_DEL. That works with some hardware keyboards, but soft keyboards often edit the text through the input connection instead of delivering a standard key press.

Here is the basic approach:

1editText.setOnKeyListener { _, keyCode, event ->
2    if (keyCode == KeyEvent.KEYCODE_DEL && event.action == KeyEvent.ACTION_DOWN) {
3        println("Backspace pressed")
4        true
5    } else {
6        false
7    }
8}

This is valid code, but it is not the most reliable solution for modern Android input behavior.

Detecting Deletion Through Text Changes

If your real goal is to know that text became shorter, a TextWatcher is usually more dependable than raw key handling.

1editText.addTextChangedListener(object : TextWatcher {
2    private var previousText = ""
3
4    override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
5        previousText = s?.toString().orEmpty()
6    }
7
8    override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
9        val currentText = s?.toString().orEmpty()
10        if (currentText.length < previousText.length) {
11            println("Text was deleted")
12        }
13    }
14
15    override fun afterTextChanged(s: Editable?) = Unit
16})

This approach does not care whether the deletion came from backspace, cut, auto-correction, or input method behavior. That is often exactly what you want for validation or UI updates.

Handling Backspace on Empty Fields

One of the most common use cases is multi-field input such as OTP codes, phone fragments, or date parts. In that case, you often need to detect backspace when the current EditText is already empty and move focus to the previous field.

For that specific problem, many developers subclass EditText and intercept input connection events:

1class BackspaceAwareEditText(
2    context: Context,
3    attrs: AttributeSet? = null
4) : AppCompatEditText(context, attrs) {
5
6    var onEmptyBackspace: (() -> Unit)? = null
7
8    override fun onCreateInputConnection(outAttrs: EditorInfo): InputConnection {
9        val base = super.onCreateInputConnection(outAttrs)
10        return object : InputConnectionWrapper(base, true) {
11            override fun deleteSurroundingText(beforeLength: Int, afterLength: Int): Boolean {
12                if (text.isNullOrEmpty() && beforeLength == 1 && afterLength == 0) {
13                    onEmptyBackspace?.invoke()
14                }
15                return super.deleteSurroundingText(beforeLength, afterLength)
16            }
17        }
18    }
19}

Usage:

otpField2.onEmptyBackspace = {
    otpField1.requestFocus()
}

That pattern is more robust for soft keyboard behavior than relying only on OnKeyListener.

Picking the Right Strategy

Use the simplest tool that matches your requirement:

• use TextWatcher if you care about text deletion as a data change
• use OnKeyListener if you specifically need hardware key events
• use a custom InputConnection approach if you must catch soft-keyboard backspace on empty input

The key is to model the user interaction correctly. "Backspace was pressed" and "text was deleted" are related, but not identical, events.

Common Pitfalls

The biggest mistake is assuming every backspace arrives as KEYCODE_DEL. On Android, many soft keyboards bypass that path.

Another mistake is returning true from OnKeyListener when you only meant to observe the event. Returning true consumes it, which can prevent the default deletion behavior.

Developers also forget to handle selection ranges. If text is selected, delete may remove more than one character, so code based only on single-character assumptions can fail.

In OTP-style UIs, moving focus during every deletion can be frustrating. Usually you only want to jump to the previous field when the current field is already empty.

Finally, test with more than one keyboard app. Gboard, Samsung Keyboard, and hardware input can behave differently.

Summary

• 'OnKeyListener can detect backspace, but it is not reliable for every soft keyboard.'
• 'TextWatcher is better when you care about text becoming shorter.'
• Custom InputConnection handling is useful for empty-field backspace behavior.
• Do not consume delete events unless you really want to override default input behavior.
• Test with real keyboards and real multi-field scenarios, not only emulator defaults.