Introduction

On AppCompat-based Android screens, the underline under an EditText is usually tint-driven rather than defined by a simple static border color. That is why changing one XML attribute often seems to work in one state and fail in another. The real fix depends on whether you want a global theme-level answer or a one-off override for a specific field.

Understand What Actually Colors the Bottom Line

With AppCompat widgets, the underline is typically tinted using theme attributes such as colorControlNormal and colorControlActivated.

In practical terms:

• Unfocused state usually follows colorControlNormal.
• Focused state usually follows colorControlActivated.
• Error or accent-heavy themes may also involve colorAccent depending on widget style and Android version.

If you only change one color in the wrong place, the widget can still switch back to another theme tint on focus.

Theme-Level Solution for Consistent App Styling

If you want all EditText fields to behave consistently, set the tint colors in your AppCompat theme.

1<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
2    <item name="colorControlNormal">@color/edittext_line_normal</item>
3    <item name="colorControlActivated">@color/edittext_line_active</item>
4    <item name="colorAccent">@color/edittext_line_active</item>
5</style>

Then use normal EditText or AppCompatEditText in layout:

1<androidx.appcompat.widget.AppCompatEditText
2    android:id="@+id/searchInput"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:hint="Search" />

This is the cleanest option when the design system wants one consistent input style across the app.

Style a Single Field Without Changing the Whole Theme

If only one input should have different underline colors, use a style or tint on that widget instead of changing the global theme.

1<androidx.appcompat.widget.AppCompatEditText
2    android:id="@+id/emailInput"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:hint="Email"
6    app:backgroundTint="@color/edittext_line_active" />

This is useful in screens with special branding or step-specific highlights. It is also safer than changing theme attributes when only one field should differ.

On some layouts you may also see android:backgroundTint. For AppCompat widgets, app:backgroundTint is usually the safer choice because it keeps the tint behavior consistent through the support library.

Programmatic Tint Update

If the underline color should react to validation or runtime state, update the tint in code.

1import android.content.res.ColorStateList
2import androidx.appcompat.app.AppCompatActivity
3import androidx.appcompat.widget.AppCompatEditText
4import androidx.core.content.ContextCompat
5
6fun tintEditTextLine(editText: AppCompatEditText, colorRes: Int) {
7    val color = ContextCompat.getColor(editText.context, colorRes)
8    editText.supportBackgroundTintList = ColorStateList.valueOf(color)
9}

This is useful when you want to switch between normal and error colors after validation runs.

State-Based Colors with Color Selectors

For focus-aware behavior, define a selector instead of one flat color.

1<?xml version="1.0" encoding="utf-8"?>
2<selector xmlns:android="http://schemas.android.com/apk/res/android">
3    <item android:state_focused="true" android:color="@color/edittext_line_active" />
4    <item android:color="@color/edittext_line_normal" />
5</selector>

Then apply it as background tint:

1<androidx.appcompat.widget.AppCompatEditText
2    android:id="@+id/usernameInput"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    app:backgroundTint="@color/edittext_line_selector" />

This gives predictable visual transitions between focus states without custom drawables.

When TextInputLayout Is the Better Choice

If the screen already uses Material-style inputs, TextInputLayout often gives more consistent underline, hint, and error behavior than trying to patch raw EditText styling.

1<com.google.android.material.textfield.TextInputLayout
2    android:layout_width="match_parent"
3    android:layout_height="wrap_content">
4
5    <com.google.android.material.textfield.TextInputEditText
6        android:layout_width="match_parent"
7        android:layout_height="wrap_content"
8        android:hint="Password" />
9
10</com.google.android.material.textfield.TextInputLayout>

If you are already deep into AppCompat v7 code, this may be a migration step rather than an immediate fix, but it usually reduces theme inconsistency over time.

Debugging Inconsistent Results

If tint changes do not appear:

• Confirm the view is actually AppCompatEditText.
• Check whether the theme overrides your per-view tint.
• Test both focused and unfocused states.
• Make sure design support or Material components are not applying a different parent style.

Underline rendering differences across API levels are common, so test on at least two Android versions before assuming the problem is solved.

Common Pitfalls

• Changing colorAccent only and expecting all underline states to update.
• Styling one EditText while the theme re-tints it on focus.
• Using the wrong widget class and missing AppCompat tint support.
• Forgetting to test state transitions such as focus and error.
• Forcing complex custom drawables when tint-based styling would be simpler.

Summary

• AppCompat EditText underline color is usually theme- and tint-driven.
• Use theme attributes for app-wide consistency.
• Use backgroundTint or supportBackgroundTintList for per-field customization.
• Use a color selector when focused and normal states need different colors.
• Consider TextInputLayout when richer Material input behavior is needed.