Colors
Android
Coding
Design
Mobile

Understanding colors on Android six characters

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Android color literals are simple once the byte order is clear, but many bugs come from mixing six-character and eight-character forms. Six-character values represent RGB only, while eight-character values add alpha in front using ARGB order. Getting this wrong often causes unexpected transparency or wrong theme contrast in production screens.

Hex Color Formats in Android

Android recognizes these common hexadecimal formats:

  • #RRGGBB for fully opaque RGB.
  • #AARRGGBB for alpha plus RGB.

Examples:

  • #1E88E5 means blue with full opacity.
  • #CC1E88E5 means same blue at about 80 percent opacity.

A common mistake is assuming eight-character values use RGBA order. Android expects alpha first.

Define Colors in Resources, Not Inline Strings

Prefer centralized color resources for consistency.

xml
1<resources>
2    <color name="brand_blue">#1E88E5</color>
3    <color name="brand_blue_80">#CC1E88E5</color>
4    <color name="warning_red">#D32F2F</color>
5</resources>

Use resource references in layouts:

xml
1<TextView
2    android:layout_width="wrap_content"
3    android:layout_height="wrap_content"
4    android:text="Status"
5    android:textColor="@color/brand_blue" />

This avoids scattered literals and makes theme updates much easier.

Parse and Apply Colors in Kotlin Safely

When you must parse runtime color strings, validate format and catch invalid input.

kotlin
1import android.graphics.Color
2
3fun parseColorOrFallback(input: String, fallback: Int): Int {
4    return try {
5        Color.parseColor(input)
6    } catch (ex: IllegalArgumentException) {
7        fallback
8    }
9}
10
11val solid = parseColorOrFallback("#1E88E5", Color.BLACK)
12val translucent = parseColorOrFallback("#CC1E88E5", Color.BLACK)

Never trust remote color strings blindly in UI-critical paths.

Theme-Aware Color Usage

Hardcoded colors often break dark mode and dynamic theming. Prefer semantic theme attributes for text and surfaces.

kotlin
1import android.util.TypedValue
2
3fun resolveThemeColor(context: android.content.Context, attr: Int): Int {
4    val value = TypedValue()
5    val ok = context.theme.resolveAttribute(attr, value, true)
6    if (!ok) error("theme attribute missing")
7    return value.data
8}

Then use Material attributes such as colorPrimary, colorOnSurface, or custom tokens. This keeps contrast behavior more reliable across themes.

Alpha and Accessibility

Alpha is useful for layering, but it can hurt readability quickly. A color that looks acceptable in one background may fail contrast requirements in another.

Practical guidance:

  • Avoid low-opacity text on patterned backgrounds.
  • Test light and dark themes with real devices.
  • Validate contrast for important controls and labels.

If underlays vary at runtime, prefer solid semantic colors over alpha blends for critical text.

Debugging Unexpected Color Output

If color results look wrong, check these in order:

  1. Literal format and byte order.
  2. Whether color comes from resource, runtime string, or theme attribute.
  3. View state overlays such as disabled alpha.
  4. Dark mode and night resource qualifiers.

For view inspection, Android Studio Layout Inspector helps confirm final rendered color and applied style chain.

Migration Strategy for Existing Codebases

Many legacy apps have inline color strings spread across XML and Kotlin files. Refactor incrementally:

  1. Create semantic color tokens in resources.
  2. Replace high-traffic screens first.
  3. Add lint rules or review checks against new inline literals.

This approach improves consistency without requiring a risky big-bang rewrite.

Also add screenshot-based UI regression checks for critical screens so unintended color drift is caught quickly after design-token or theme updates.

Common Pitfalls

A common pitfall is treating #AARRGGBB as RGBA and accidentally swapping alpha with red. Another issue is mixing hardcoded literals with theme attributes in the same screen, which causes dark mode inconsistencies. Teams also underestimate how disabled-state overlays alter perceived color values. Using alpha-heavy text colors is another frequent accessibility failure. Finally, parsing remote color strings without validation can crash UI paths or introduce unreadable combinations.

Summary

  • Android six-character colors are RGB, and eight-character colors are ARGB.
  • Put colors in resources and prefer semantic theme tokens.
  • Validate runtime color strings and provide safe fallbacks.
  • Use alpha carefully, especially for text and important controls.
  • Test final contrast and appearance across light and dark themes.

Course illustration
Course illustration

All Rights Reserved.