painterResource() ignores ColorStateLists completely when inflating android:tint in VectorDrawables [195668138]

Fixed

Bug

Status Update

No update yet.

Description

al...@gmail.com

created issue #1

Aug 6, 2021 02:17AM

Current incorrect behavior

The painterResource() currently only supports inflating android:tint if it references a simple COLOR_INT resource type, meaning that ColorStateLists or theme attributes pointing to ColorStateLists are simply ignored (link to source code).

Desired correct behavior

android:tint should inflate the color state list using TypedArrayUtils#getNamedColor() instead, which would default to the ColorStateList's default value (since Compose does not have any understanding of drawable states used with Views).

This behavior would mirror the way that ColorStateLists are currently handled in a <path>'s android:fillColor and android:strokeColor, both of which fallback to the ColorStateList's default color (they inflate using TypedArrayUtils#getNamedComplexColor() here, which returns a ComplexColor wrapper around a ColorStateList. Then when the vector is rendered to the display, a simple SolidColor using the color state list's default color is returned here).

This would closely mirror the way that VectorDrawableCompat is inflated, which uses TypedArrayUtils#getNamedColorStateList() (source code here).

Reasons for fixing the bug

android:fillColor and android:strokeColor currently support color state lists but android:tint does not. Ideally they should both be supported if possible.
Many teams adopting Compose don't have an Icon solution as elegant as Material's (which generates ImageVectors as part of a separate artifact automatically). For example, our team, plans to continue inflating icons from our existing icon library defined in XML resources while adopting Compose, and all of these resources currently declare a default tint color using android:tint.

Version used: Compose v1.0.1

Comments

nj...@google.com <nj...@google.com> Aug 6, 2021 02:56AM

Assigned to nj...@google.com.

ap...@google.com <ap...@google.com> #2Aug 11, 2021 11:09PM

Marked as fixed.

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Issue 195668138