Introduction

When Android 6.0 deprecated getResources().getColor(int), a lot of old code suddenly showed warnings even though it still ran. The deprecation was about API design, not sudden failure. Android wanted color resolution to be more explicit about theme handling and more consistent across app versions.

Why the Old Method Was Deprecated

The old code looked like this:

int accent = getResources().getColor(R.color.accent);

That method returned a color integer, but it did not accept a theme parameter. As Android styling became more dependent on themes, stateful resources, and later dark-mode style behavior, the framework introduced the theme-aware overload:

int accent = getResources().getColor(R.color.accent, getTheme());

The newer method makes resource resolution more explicit. That is the real reason the older form was deprecated.

The Practical Replacement for App Code

In most applications, the easiest fix is not to call the API-23 framework overload directly. The usual replacement is ContextCompat.getColor, which hides version differences and gives you one clear call site.

Kotlin:

import androidx.core.content.ContextCompat

val accent = ContextCompat.getColor(this, R.color.accent)

Java:

import androidx.core.content.ContextCompat;

int accent = ContextCompat.getColor(this, R.color.accent);

This is the standard migration because it is short, readable, and works well in compatibility-focused code.

Use the Right Context

The Context you pass still matters:

• use this inside an Activity
• use requireContext() inside a Fragment
• pass an appropriate UI context into helpers or adapters

For example:

1class SummaryFragment : Fragment(R.layout.fragment_summary) {
2    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
3        val warning = ContextCompat.getColor(requireContext(), R.color.warning)
4        view.findViewById<TextView>(R.id.statusText).setTextColor(warning)
5    }
6}

If the fragment is detached, requireContext() will fail. That is a lifecycle issue rather than a color-API issue, but it often appears during the same migration.

Fixed Color Resources Versus Theme Attributes

Not every UI color should come from a fixed resource id. Sometimes the design really means "use the current theme's primary color" rather than "use this one exact color resource." In that case, a theme-attribute lookup may be more correct than a direct color-resource fetch.

That means a deprecation cleanup is also a good time to ask whether the code should be using:

• a fixed color resource
• a theme attribute
• a stateful color resource

Replacing the API call is the minimum fix. Rechecking the color model is the better fix.

Do Not Confuse Color Ints with ColorStateList

A plain color integer works only when the value never changes with view state. If a button or label needs different colors for pressed, disabled, or selected states, use ColorStateList instead.

val colors = ContextCompat.getColorStateList(requireContext(), R.color.primary_button_text)
button.setTextColor(colors)

That distinction matters because some codebases migrate away from deprecated getColor calls but still keep the wrong abstraction for stateful UI.

Common Pitfalls

• Replacing the old call blindly when the code really needs a theme attribute lookup.
• Passing an invalid context from a detached fragment or a long-lived helper object.
• Treating stateful color resources as if they were plain color integers.
• Assuming the deprecation means immediate runtime failure instead of a better-API warning.
• Removing the warning without testing theme-dependent screens afterward.

Summary

• 'getResources().getColor(int) was deprecated because theme-aware color resolution needed a clearer API.'
• 'ContextCompat.getColor(context, id) is the practical replacement for most app code.'
• Use a valid lifecycle-safe context when resolving colors.
• Distinguish fixed colors from theme attributes and ColorStateList usage.
• Use the migration as a chance to improve color handling, not only to silence the warning.