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:
#RRGGBBfor fully opaque RGB.#AARRGGBBfor alpha plus RGB.
Examples:
#1E88E5means blue with full opacity.#CC1E88E5means 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.
Use resource references in layouts:
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.
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.
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:
- Literal format and byte order.
- Whether color comes from resource, runtime string, or theme attribute.
- View state overlays such as disabled alpha.
- 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:
- Create semantic color tokens in resources.
- Replace high-traffic screens first.
- 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.

