Why 'drawable selector' not works when have resource ID 0x7f020000?

129 views
Skip to first unread message

Build Account

unread,
May 5, 2012, 8:49:03 AM5/5/12
to adt-dev
Hello.

Regarding tje issue #29934
(http://code.google.com/p/android/issues/detail?id=29934),
could you please look in to from this team?

Thx.

Christopher Orr

unread,
May 5, 2012, 7:02:27 PM5/5/12
to adt...@googlegroups.com
Hi there,
This isn't a tools issue; I had the same problem a long time ago, found
the cause in the code, and then happily discovered that it had just been
fixed in AOSP.

The issue and fix are mentioned here:
https://code.google.com/p/android/issues/detail?id=20283#c6

Regards,
Chris

Tor Norbye

unread,
May 7, 2012, 12:43:05 PM5/7/12
to adt...@googlegroups.com
This seems like an ideal candidate for a lint check -- since this
issue was fixed in Honeycomb, the lint check would look at the
minSdkVersion in the manifest, and if you're targeting a pre-Honeycomb
version, AND <bug condition>, then make sure you have a dummy asset
occupying the first drawable resource slot.

I haven't studied the fix so I'm not entirely sure what the bug
condition is. Is it really that the first drawable resource can be
clobbered? Or are there further limitations (e.g. the bug reports
talks about the drawable/ directory, though I would think
drawable-mdpi etc all go to the same place in the resource table).

-- Tor

Tor Norbye

unread,
May 7, 2012, 5:29:08 PM5/7/12
to adt...@googlegroups.com
Do you (or any one else) have a project which reproduces this problem?

Specifically I'm interested in figuring out what it is the code is
doing to trigger this. From talking to Dianne about it, it sounds like
this bug can happen if (in an older version) you set a color that
happens to have alpha value "7f". However, the rest of the number can
vary (02 is assigned based on the resource type, dynamically assigned
by aapt). You only get a conflict if the color matches this exactly --
and crucially, this may not always touch the first spot. For example,
if I understand correctly, if the color you set was 0x7f020001 you'd
clobber the second resource instead, which would make the a.png
workaround not work. Thus, the workaround (and lint diagnostic)
needs to look for conflicting color declarations, but it would help a
lot to see some specific code where this happens to understand how.

-- Tor
Reply all
Reply to author
Forward
0 new messages