fix(android): box shadow and border radius white border resolution

[vallemar]

When you have a dark screen and you apply box-shadow and border radius you see a rather strange white border. Applying this change solves it. I haven't seen any difference on a clear screen, so I think it doesn't break anything

Old:

Fix:

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit dc3e10c. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 2 targets

• nx run-many --target=test --configuration=ci --projects=core
• nx run webpack5:build

---

Sent with 💌 from NxCloud.

[rigor789]

Mentioned on Discord already, just adding here for visibility:

The WHITE rect layer is added to mimic the web behavior:

So setting it to TRANSPARENT is redundant, as we might as well not even add the overlay layer in that case. A proposed solution is to check whether the view already has a background, and only in case it doesn't add the white rect overlay, otherwise skip adding the overlay layer at all.

[vallemar]

@rigor789 I had misunderstood you, I thought it was just the passing of the color, now the layer will not be added if it already has a background

[vallemar]

@NathanWalker @rigor789 can we review this pr?

[rigor789]

This might be unsafe, this.wrappedLayer might not always be a BorderDrawable, so casting to it can lead to exceptions. A safer approach would be to check the type of wrappedLayer.

[vallemar]

@rigor789 @NathanWalker I have updated the PR with the type check

[rigor789]

Looks good to me, just left some small nits about the method naming. 👍

[NathanWalker]

This PR is invalid at this point but if fixed we could include with 8.5 still.

ns-android-box-shadow-pr-invalid.mov

[rigor789]

Simplified the logic to hide the overlay layer when the wrapped drawable has a background color, image or gradient. The above issue was caused by changing the order of the addLayer calls mainly. Might still try not creating the layer at all - but the order of layers important.

[rigor789]

Refactored to not create the layer as originally intended - but preserving the order of layers now correctly.

[vallemar]

@rigor789 oh sorry, I thought the order wouldn't matter and put it in an order that I thought was more readable