Introduction

Selecting all text when an EditText gains focus is a common Android UX pattern for search boxes, numeric inputs, and editable defaults. The goal is simple: when the user taps into the field, the existing text is highlighted so it can be replaced immediately.

The Simplest Option: XML

Android already provides a built-in attribute for this behavior.

1<EditText
2    android:id="@+id/nameInput"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:selectAllOnFocus="true"
6    android:text="Existing value" />

If the field receives focus through normal UI interaction, this is often enough. It is the cleanest option because it keeps the behavior declarative and easy to see in the layout.

Programmatic Focus Handling in Kotlin

Sometimes you need more control, especially when the focus is assigned from code or when the field participates in a more complex form. In that case, listen for focus changes and select the text explicitly.

1val editText = findViewById<EditText>(R.id.nameInput)
2
3editText.setOnFocusChangeListener { view, hasFocus ->
4    if (hasFocus) {
5        (view as EditText).post {
6            view.selectAll()
7        }
8    }
9}

Using post is important in many real screens because it runs the selection after the focus event has completed. Without it, the cursor placement logic can override your selection.

Java Version

If the project is still in Java, the same pattern works there too.

1EditText editText = findViewById(R.id.nameInput);
2
3editText.setOnFocusChangeListener((view, hasFocus) -> {
4    if (hasFocus) {
5        EditText field = (EditText) view;
6        field.post(field::selectAll);
7    }
8});

This is a good default when the XML attribute alone is not reliable enough for the screen’s focus timing.

Handling the First Tap Cleanly

One subtle issue is touch behavior. A tap can both request focus and position the cursor, which may clear the full selection immediately. If that happens on your screen, keep the selection logic delayed through post, or trigger it only for specific focus transitions such as first entry into the field.

That is also why this behavior can feel inconsistent when copied between activities, fragments, dialogs, and recycled list items. Focus timing differs.

When Not to Use It

Selecting all text on focus is helpful when users usually replace the whole value. It is annoying when users more often edit a value in place. For long text or mixed editing patterns, automatic full selection can work against user intent.

Good UX here is contextual. Use it for short replaceable fields, not as a blanket rule for every EditText.

Special Cases in Dialogs and Recycled Views

This behavior often needs extra care inside dialogs, fragments, and list-based UIs such as RecyclerView. Views in those containers can be rebound or refocused during lifecycle changes, which means your selection logic may run more than once or at the wrong time. If you see flickering selection or a cursor that jumps unexpectedly, confirm that the listener is attached only once and that the field is actually focused before calling selectAll().

Common Pitfalls

• Relying only on selectAll() without post can fail because the cursor update happens later.
• Applying full selection to every text field can create a frustrating editing experience.
• Forgetting that focus behavior differs between touch input and programmatic focus leads to inconsistent results.
• Testing only in one screen can miss issues that appear inside dialogs, fragments, or list rows.
• Selecting text before the view is attached or focused does nothing.

Summary

• 'android:selectAllOnFocus="true" is the simplest built-in solution.'
• For more control, use a focus-change listener and call selectAll() after focus settles.
• 'post helps prevent cursor placement from overriding the selection.'
• This pattern works best for short fields that users usually replace entirely.
• Test touch and programmatic focus paths, because they do not always behave identically.