How to Change the Font Color in Android: Easy Steps

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="Notifications"

android:textColor="@color/brand_text_secondary" />

According to Google Android documentation, themes and resources can be overridden for different configurations (such as night mode) by placing alternate resources under `res/values-night/`. This is why resource-based colors are a dependable starting point in 2025.

Q: Should I use hex colors or color resources in XML?
Use color resources (e.g., `@color/…`) for maintainability and theme support; use hex values only for quick prototyping.

Change Font Color Programmatically (Kotlin/Java)

Set the font color at runtime by calling `setTextColor()` on your `TextView`. This is the right choice when the color depends on user actions, permissions, API results, or feature flags.

`TextView.setTextColor(int color)` changes the text color at runtime without requiring a layout reload.

Parsing a string with `Color.parseColor("#RRGGBB")` produces an ARGB color int suitable for `setTextColor()`.

Android’s `ContextCompat.getColor(context, R.color.… )` is the recommended compatibility approach for retrieving color resources.

Use `textView.setTextColor(Color.parseColor("#RRGGBB"))`

If you receive a color from a server or remote config, you’ll often start with a hex string. For example, if a backend returns `#1E88E5` (blue), you can apply it like this:

val colorString = "#1E88E5" // Example from remote config

val parsedColor = android.graphics.Color.parseColor(colorString)

titleTextView.setTextColor(parsedColor)

String colorString = "#1E88E5"; // Example from remote config

int parsedColor = android.graphics.Color.parseColor(colorString);

titleTextView.setTextColor(parsedColor);

In my testing, I found that `parseColor()` is reliable for `#RRGGBB` and `#AARRGGBB` formats. However, you should validate or catch `IllegalArgumentException` when the string may be malformed.

Prefer color resources with `ContextCompat.getColor()` for consistency

If the color is known at build time (like “success text” or “warning text”), prefer resources over parsing.

val successColor = androidx.core.content.ContextCompat.getColor(

context,

R.color.status_success_text

)

statusTextView.setTextColor(successColor)

int successColor = androidx.core.content.ContextCompat.getColor(

context,

R.color.status_success_text

);

statusTextView.setTextColor(successColor);

According to Android Developers, `ContextCompat` helps with compatibility across API levels. This means your “font color in Android” logic behaves consistently in real-world deployments.

Q: When is programmatic color change better than XML?
When the color depends on runtime conditions (user selection, network data, validation results, or permissions).

Quick comparison (XML vs code):

Use Color Resources for Cleaner and Reusable Styling

Use color resources to centralize font colors and keep your UI consistent as the app grows. When you define colors once in `res/values/colors.xml`, you reuse them across multiple `TextView` instances and even entire screens.

Defining colors in `res/values/colors.xml` and referencing them as `@color/...` is the standard approach for reusable styling.

Central color resources reduce regressions because the same UI token can be updated in one place.

Resource-based colors are compatible with configuration overrides like `res/values-night/` for dark mode.

Define colors in `res/values/colors.xml`

A typical color token set might include primary, secondary, success, warning, and error text colors.

Then reference them in layouts or in code:

android:textColor="@color/brand_text_secondary"

Reuse the same colors across multiple TextViews and screens

This is where the approach pays off in maintenance. Instead of hunting through dozens of layouts, you update token values once. In my experience supporting multiple feature teams, consistent color resources also make design QA faster because testers can focus on semantic states (success/error/warning) rather than arbitrary hex codes.

According to W3C Web Content Accessibility Guidelines (WCAG) , contrast requirements help readability, and while Android text contrast is nuanced (font size, weight, and background), relying on a controlled set of semantic color tokens makes it easier to satisfy accessibility targets. (WCAG is not Android-specific, but it directly influences practical UI color decisions.)

Q: What are “semantic” colors in Android?
Semantic colors represent meaning (like success or error) rather than appearance, and they map to token values in `colors.xml`.

Handle State-Based Colors (Enabled/Pressed/Selected)

Use state-based colors when the same `TextView` must visually communicate interaction states like enabled/disabled or pressed/selected. The right tool is `ColorStateList`, which maps view states to different text colors.

`ColorStateList` lets you define different text colors for different view states such as `state_enabled` and `state_pressed`.

Applying a `ColorStateList` via `setTextColor(colorStateList)` updates a TextView’s text color automatically as states change.

Create a `ColorStateList` to switch colors by view state

You typically define state mapping in XML and then apply it, or you build it in code.

XML example:

Kotlin application:

val colorStateList = androidx.core.content.ContextCompat.getColorStateList(

context,

R.color.text_color_button

)

textView.setTextColor(colorStateList)

In my debugging, state lists resolve a common issue where developers set one color in code but forget that press/disabled styling from themes or selectors overrides it.

Apply the state list to text with `setTextColor(colorStateList)`

When you call `setTextColor(colorStateList)`, Android will pick the correct color based on the current state set on the view. This becomes especially powerful for custom components—say a reusable “pill” label that changes color when selected or disabled.

Pros/cons of state lists:

Q: Do state-based text colors work with themes?
Yes. You can combine themes with `ColorStateList` by referencing themed color resources (and overriding tokens for night mode).

Apply Font Color in Themes and Styles

Set default font colors through styles so you don’t repeat the same `textColor` everywhere. Themes and styles are the most scalable approach when your app has many `TextView` instances and you want consistent brand typography.

Android styles can define default `android:textColor` for `TextView` or custom text appearances.

Using styles reduces duplication, making UI updates faster and less error-prone than editing each layout file.

Set default text colors via styles to avoid repeating code

Instead of specifying `android:textColor` on every `TextView`, create a style and apply it via `style="@style/..."` or `android:textAppearance` depending on your design system.

Example style:

Apply it: