Introduction

Disabling an EditText in Android is not just a one-line property change. In practice, there are at least two different product requirements: a truly disabled field that users cannot interact with at all, and a read-only field that still looks active and may allow text selection or copying. Choosing the wrong mode usually produces either poor accessibility or confusing UI behavior.

Decide Whether You Want Disabled or Read-Only

A disabled field communicates "this control is inactive." A read-only field communicates "this value exists, but the user should not edit it." Those are different experiences and should be implemented deliberately.

If the field should be unavailable because a workflow step is locked or a permission is missing, disabling is usually correct. If the field displays a generated value such as an account ID or total amount, read-only is often better because users may still want to select and copy the text.

Static Disabled State in XML

If a field is always disabled, set it directly in the layout. That keeps the default behavior obvious and prevents inconsistent setup code from multiple fragments or activities.

1<EditText
2    android:id="@+id/accountId"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:enabled="false"
6    android:text="A-004291"
7    android:hint="Account ID" />

This blocks interaction and lets Android apply the disabled visual state. It is simple, but it is only appropriate when the field should truly be inactive.

Dynamic Read-Only Behavior in Kotlin

If the field must remain visible and readable while blocking edits, use a read-only pattern rather than hard disabling it. One practical approach is to remove the key listener and focusability while keeping the view enabled.

1private fun setReadOnly(field: EditText, readOnly: Boolean) {
2    if (readOnly) {
3        if (field.tag == null) field.tag = field.keyListener
4        field.isEnabled = true
5        field.isFocusable = false
6        field.isFocusableInTouchMode = false
7        field.keyListener = null
8    } else {
9        field.keyListener = field.tag as? android.text.method.KeyListener
10        field.isEnabled = true
11        field.isFocusable = true
12        field.isFocusableInTouchMode = true
13    }
14}

This keeps the text readable and can preserve copy-friendly behavior better than a fully disabled view.

Keep Visual State and Accessibility Aligned

Whatever interaction mode you choose, make sure the UI tells the truth. A field that looks active but ignores input is frustrating. A field that looks disabled but still opens the keyboard is worse.

When the lock state changes dynamically, update supporting text and accessibility information so screen-reader users understand what happened. If the text is important to read, keep contrast strong enough even when editing is disabled. Disabled should not mean illegible.

Test Keyboard, Focus, and State Restoration

EditText behavior is affected by focus handling, IME interaction, and configuration changes. A field that seems correctly locked in one flow may start accepting input again after rotation if the state is not restored from the view model or saved state.

A small UI test helps catch regressions:

1@Test
2fun totalField_readOnly_ignoresTyping() {
3    ActivityScenario.launch(FormActivity::class.java)
4
5    onView(withId(R.id.totalField)).perform(click())
6    onView(withId(R.id.toggleReadOnly)).perform(click())
7    onView(withId(R.id.totalField)).perform(typeText("123"))
8    onView(withId(R.id.totalField)).check(matches(withText("4500")))
9}

This kind of test verifies the behavior the user cares about, not just the property values on the widget.

Centralize the Logic

Forms become inconsistent when each screen invents its own locking trick. One layout sets enabled to false, another sets focusable only, and a third removes the key listener without restoring it correctly. A shared helper keeps the behavior consistent and easier to audit.

It also reduces subtle bugs around autofill, copy behavior, and visual styling, because one place owns the policy.

Common Pitfalls

The most common mistake is treating disabled and read-only as the same thing. Another is setting only one property, such as isFocusable = false, and assuming that covers every input path. Teams also often forget accessibility messaging, or they fail to restore the chosen state after configuration changes and fragment recreation.

Summary

• Decide first whether the field should be disabled or read-only.
• Use XML for fixed disabled state and code for dynamic locking behavior.
• Keep visuals, interaction rules, and accessibility messaging consistent.
• Test focus and typing behavior, not just widget properties.
• Centralize EditText locking logic so forms behave the same way across the app.