IssueTracker

I haven't seen gradients with items defining the offsets before. It seems that not only breaks when used inside aapt:attr but also as a standalone gradient.

After a bit of investigation, it seems like fillColor might not be accepting anything that it's not a solid color. I've removed the aapt:attr usage and used a regular gradient without items and the problem still exists.

Move it to P2 as discussion.

This issue affects most icons designed according to https://material.io/guidelines/style/icons.html#icons-product-icons. What is the reasoning for not treating it as P1?

The reasoning was that this is not a regression and, at least in the example, seems to mainly affect the shadow. It does not break the user interaction with the layout editor and there is a workaround available (simply defining the gradient within a color/ file).
Also, I haven't seen many instances of appt:attr definitions for the fillColor (in google3 we have only 1).

If we still feel this is a P1, please feel free to bump it back and we'll look into it ASAP.

Ok, I've spent some time having a look to it and it seems I could have a fix for it. It will require a new layoutlib though so we need to decide if we want to put it in a new beta

The pattern of using gradient in the ic_launcher_foreground.xml file attached to comment #1 is typical for a result of importing an SVG file to Studio. Given that most images are produced this way and that a significant fraction, if not majority, contain gradients, it is critical to fix this problem not later than in 3.1 time frame.

Fair enough. Fix in ag/2852336

BTW this does not affect all gradients. It affects to gradients declared within aapt:attr.
Gradients declared within the colors/ folder or within shapes in drawables/ work fine.

When will the fix land in Studio?

The fix is in master already and will be in the next beta