Introduction

EditText can display compound drawables on the left, right, top, or bottom, but those drawables do not have their own click listeners. To handle taps on one of them, you usually intercept touch events on the EditText and check whether the touch position falls inside the drawable's visible bounds.

Why This Needs Manual Hit Testing

A compound drawable attached with setCompoundDrawables or setCompoundDrawablesWithIntrinsicBounds is not a separate View. It is just drawn as part of the EditText.

That means Android does not give you a built-in callback such as "right drawable clicked." You have to detect it yourself.

A Common Right-Drawable Example

A frequent use case is a clear-text icon placed at the end of the field.

1editText.setOnTouchListener { v, event ->
2    if (event.action == MotionEvent.ACTION_UP) {
3        val drawableEnd = editText.compoundDrawablesRelative[2]
4        if (drawableEnd != null) {
5            val drawableWidth = drawableEnd.bounds.width()
6            val isInside = event.x >= (editText.width - editText.paddingEnd - drawableWidth)
7            if (isInside) {
8                editText.text?.clear()
9                return@setOnTouchListener true
10            }
11        }
12    }
13    false
14}

This checks whether the touch landed in the horizontal area occupied by the end drawable.

Why Relative Drawables Are Better

Notice the use of compoundDrawablesRelative. That is often better than compoundDrawables because it respects layout direction.

With left-to-right layouts, the end drawable is on the right. With right-to-left layouts, it may appear on the left. If your app supports RTL languages, using relative APIs avoids subtle UI bugs.

Touch Logic Needs Padding Awareness

A common mistake is checking only the raw drawable width. The touch area should usually account for:

• the view width
• end padding
• drawable bounds
• sometimes additional hit slop for easier tapping

If the field is narrow or the drawable is small, extending the clickable region slightly can improve usability.

A Reusable Subclass Approach

If you use this pattern often, move it into a custom AppCompatEditText subclass.

1class DrawableClickEditText @JvmOverloads constructor(
2    context: Context,
3    attrs: AttributeSet? = null,
4    defStyleAttr: Int = androidx.appcompat.R.attr.editTextStyle
5) : AppCompatEditText(context, attrs, defStyleAttr) {
6
7    var onEndDrawableClick: (() -> Unit)? = null
8
9    override fun onTouchEvent(event: MotionEvent): Boolean {
10        if (event.action == MotionEvent.ACTION_UP) {
11            val drawableEnd = compoundDrawablesRelative[2]
12            if (drawableEnd != null) {
13                val hitStart = width - paddingEnd - drawableEnd.bounds.width()
14                if (event.x >= hitStart) {
15                    onEndDrawableClick?.invoke()
16                    return true
17                }
18            }
19        }
20        return super.onTouchEvent(event)
21    }
22}

This keeps view-controller code cleaner and makes the interaction reusable.

Accessibility Considerations

Because the drawable is not a separate accessible element, users of accessibility services may not get the same affordance as they would from a real button.

If the drawable performs an important action, consider whether a separate ImageButton, end icon in TextInputLayout, or another more explicit control would be better.

For Material-based UIs, TextInputLayout often gives a cleaner built-in end-icon solution than custom touch logic on a raw EditText.

Common Pitfalls

The biggest mistake is forgetting that a drawable is not a child view and therefore cannot receive its own click listener.

Another mistake is ignoring layout direction and hardcoding right-side assumptions instead of using relative drawables.

A third issue is hit testing without accounting for padding, which makes taps near the icon behave inconsistently.

Finally, if the drawable action is important, think carefully about accessibility and discoverability before hiding it inside a text field.

Summary

• Compound drawables in EditText do not have built-in click listeners.
• Detect drawable taps by intercepting touch events and hit-testing the drawable area.
• Prefer compoundDrawablesRelative for proper RTL behavior.
• Include padding and practical touch area in the hit-test calculation.
• Wrap the pattern in a custom view if you use it repeatedly.
• For important actions, consider using a more explicit and accessible UI component.