Introduction

ColorStateList lets an Android view use different colors for different states such as pressed, disabled, selected, or checked. Creating it programmatically is useful when the colors depend on runtime conditions, theme values, or reusable UI logic that does not belong in a static XML resource.

A ColorStateList Is Just States Plus Colors

At runtime, a ColorStateList is built from two parallel arrays:

• one array of state specifications
• one array of colors that correspond to those specifications

Android checks the state specs from top to bottom and uses the first match. That ordering matters. More specific states should appear before the default fallback.

Basic Kotlin Example

Here is a small example that colors a button red when pressed, gray when disabled, and blue otherwise.

1import android.content.res.ColorStateList
2import android.graphics.Color
3
4val states = arrayOf(
5    intArrayOf(-android.R.attr.state_enabled),
6    intArrayOf(android.R.attr.state_pressed),
7    intArrayOf()
8)
9
10val colors = intArrayOf(
11    Color.GRAY,
12    Color.RED,
13    Color.BLUE
14)
15
16val colorStateList = ColorStateList(states, colors)

The empty intArrayOf() at the end is the default state. Without it, you risk missing a fallback color when no other state matches.

Applying It to a View

What you do next depends on the target property. For text colors, apply it with setTextColor. For button tints or image tints, use the relevant tint API.

myButton.setTextColor(colorStateList)

For background tint on newer Android APIs:

myButton.backgroundTintList = colorStateList

The same ColorStateList object can often be reused across multiple views if the state logic is identical.

Java Version

If your project uses Java instead of Kotlin, the construction pattern is the same.

1import android.content.res.ColorStateList;
2import android.graphics.Color;
3
4int[][] states = new int[][] {
5    new int[] {-android.R.attr.state_enabled},
6    new int[] {android.R.attr.state_pressed},
7    new int[] {}
8};
9
10int[] colors = new int[] {
11    Color.GRAY,
12    Color.RED,
13    Color.BLUE
14};
15
16ColorStateList colorStateList = new ColorStateList(states, colors);
17button.setTextColor(colorStateList);

The key point is still the same: order the state specs from most specific to least specific.

Common State Patterns

Some state arrays appear frequently:

• 'android.R.attr.state_pressed'
• 'android.R.attr.state_enabled'
• 'android.R.attr.state_checked'
• 'android.R.attr.state_selected'

A negative prefix means the state must be absent. For example, -android.R.attr.state_enabled matches disabled views.

1val checkedStates = arrayOf(
2    intArrayOf(android.R.attr.state_checked),
3    intArrayOf()
4)

That pattern is common for checkboxes, radio buttons, and toggle-style widgets.

Prefer Theme Colors When Possible

Hard-coded colors are fine for a focused example, but production UIs often need theme-aware values. You can resolve colors from the current theme and then build the ColorStateList from those values.

val primary = 0xFF1976D2.toInt()
val disabled = 0xFF9E9E9E.toInt()
val pressed = 0xFFD32F2F.toInt()

In a real app, you would usually resolve these through theme attributes or resource colors so dark mode and brand styling stay consistent.

When XML Is Better

Programmatic creation is useful, but not always necessary. If the colors are static, an XML selector resource is easier to inspect and reuse. Programmatic construction is best when:

• colors depend on runtime conditions
• the same logic is generated dynamically
• you are building a custom view or library component
• theming happens in code rather than resources

The question is not which approach is always better, but which one expresses the source of truth more clearly.

Common Pitfalls

• Forgetting to include a default empty state at the end of the state array list.
• Ordering the states incorrectly so the default rule matches before a specific rule can apply.
• Using the wrong target API, such as setting text color when you intended a background or image tint.
• Hard-coding colors when the component should respect the active app theme.
• Recreating identical ColorStateList objects repeatedly instead of reusing them.

Summary

• 'ColorStateList maps view states to colors.'
• Create it with parallel arrays of state specs and colors.
• Put specific states first and a default empty state last.
• Apply it to text, tint, or other color-aware properties depending on the view.
• Use programmatic construction when state colors depend on runtime logic or dynamic theming.