58

Recently I've seen appeared a lint error in my code:

Should pass resolved color instead of resource id here: getResources().getColor(R.color.maps_list_background_color)
MyClass.java /myapp/android/maps line 107 Android Lint Problem

I know how to resolve it the answer is in the error, the thing is I don't get why they have added this error in the linter.

Alexander Farber
  • 21,519
  • 75
  • 241
  • 416
Leoz
  • 733
  • 1
  • 7
  • 10

7 Answers7

60

Methods that take a color in the form of an integer should be passed an RGB triple, not the actual color resource id. You must call getResources.getColor(resource).

The function you are calling is expecting an integer that is an RGB triple, not just the id of a color resource. The color resource id is still an integer, but would not produce the color that you are expecting if it was used as the RGB triple. In order to pass it the correct RGB triple for your color, you must resolve it with the getResources().getColor(R.color.example_color) call.

ter0
  • 992
  • 8
  • 12
  • 6
    This lint error seems to show even for user-created methods that have the word 'color' in them. I thought that adding `@ColorRes` to the `int` paramater would remove this error, but it did not. – Jason Robinson Dec 12 '14 at 22:41
  • 3
    @JasonRobinson more specifically, if your method ends with the word `color`. I just made my method named `setButtonColorInt` and warning went away. – Adam Johns Jul 21 '15 at 21:49
  • 1
    you might need to add 'ContextName'.getResources().getColor(..) – smoothumut Feb 16 '16 at 07:02
59

Since I'm still finding this on Google and it is deprecated, I thought I'd might as well share the current method of doing this.

check getResources().getColor() is deprecated

ContextCompat.getColor(getApplicationContext(), R.color.color_name)
GeneCode
  • 7,545
  • 8
  • 50
  • 85
Raymond
  • 2,276
  • 2
  • 20
  • 34
  • in my case ContexCompat has no getColor method – smoothumut Feb 16 '16 at 07:02
  • 1
    http://developer.android.com/reference/android/support/v4/content/ContextCompat.html#getColor(android.content.Context, int) it does. Also not sure if you copy pasted from your code, because there is a typo in ContextCompat (missing t) – Raymond Feb 16 '16 at 07:08
  • 2
    AWESOMEEEEE, thanks a lot this also handles the hassle of api<17 when using getResources().getColor(id,theme) thanks a lot – Bassem Wissa Sep 01 '16 at 12:34
7

Use annotation @ColorInt to confirm that this is color not a color reference id.

See: android.support.annotation.ColorInt

Maher Abuthraa
  • 17,493
  • 11
  • 81
  • 103
  • Thanks, this is what I was looking for (the warning seems ok, but this is an elegant way to disable it if you know what you're doing...) – Orabîg Nov 02 '16 at 11:34
7

Since getResources().getColor() is deprecated, you need to do this to get the color:

int color = ContextCompat.getColor(getContext(),your_color_id);

Now you have the color with respect to the current context Set the color using:

your_view.setBackgroundColor(color);
MSeifert
  • 145,886
  • 38
  • 333
  • 352
tsuki
  • 155
  • 1
  • 3
  • 9
4

As for me, it's very stupid warning.

I have own class with function:

public static final void setBackgroundColor(View v, int id) {
// Here I get color by id from resources and setBackgroundColor of this color.
}

Anyway, if I try call setBackgroundColor, I get warning. But why?

So, I did simple: rename setBackgroundColor to setBackgroundColorr.

This warning activate if found name color at function name.

And yes, I do not like name setColorBackground or any other :-)

Yura Shinkarev
  • 5,134
  • 7
  • 34
  • 57
0

If you're using androidx, you can do:

requireContext().getColor(R.color.myColor);
AndrWeisR
  • 1,110
  • 11
  • 21
-2

Apparently this is caused by lint; third bullet down.

New Lint Rules

You could probably surpress this, or try implementing their syntax.

Jon
  • 377
  • 3
  • 7
  • Yep but it still doesn't explain why they have added this rule in the linter and how they detect that this int is a resource id instead of a color – Leoz Jul 04 '13 at 08:03
  • From the accepted answer, it seems like suppressing this would be a bad idea. – Martin Devillers Jul 02 '15 at 16:28