Shadow.Radius on Android13 [API 33] is broken

[Stedy59]

Description

<Shadow Opacity="1"
		Offset="10,10"
		Radius="50"
		Brush="Red"></Shadow>

on an Image and Label following: API 31 left / API 33 right

Steps to Reproduce

add shadow to XAML element

Link to public reproduction project repository

n/a

Version with bug

6.0.486 (current)

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

Android 13

Did you find any workaround?

No response

Relevant log output

No response

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[jsuarezruiz]

https://issuetracker.google.com/issues/244121207

[jsuarezruiz]

https://issuetracker.google.com/issues/238769745

[jsuarezruiz]

The TP1A.220905 build fixed that problem.

[Mous625]

Hi @jsuarezruiz, any news regarding this issue? Unfortunately, it is quite detrimental to my (and I'm sure many others) apps' design which was scheduled to be released for production this month.

[Stedy59]

I checked against the new API 33 build and all was good. When will MS push out this new emulator build?

[Mous625]

@Stedy59 as far as I know the issue is only present in Android 13 - API 33

[Stedy59]

Switch your Android SDK Manager to the Google feed and update your Android 13 - API33 emulator build to v7.
That version includes the Android OS fix.

[Mous625]

@Stedy59 Indeed it fixes the issue (on emulator).

[Mous625]

Any news on when this issue will be fixed? The issue still occurs on physical devices such as the Samsung galaxy ultra s22 with the latest updates.

[South2AK]

Is there any news on this?

[LxyFlorian]

Looking for news too. The issue still occurs on physical device such as the Galaxy A13 with Android 13 - API 33

[ghost]

Hi @Stedy59. We have added the "s/try-latest-version" label to this issue, which indicates that we'd like you to try and reproduce this issue on the latest available public version. This can happen because we think that this issue was fixed in a version that has just been released, or the information provided by you indicates that you might be working with an older version.

You can install the latest version by installing the latest Visual Studio (Preview) with the .NET MAUI workload installed. If the issue still persists, please let us know with any additional details and ideally a reproduction project provided through a GitHub repository.

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[jinxinjuan]

Verified this issue with Visual Studio Enterprise 17.7.0 Preview 2.0. Not repro on Android API-33 platform with attached project. Issue 10401.zip

[Stedy59]

As @jsuarezruiz pointed out, the issue was from a bug in Android 13. Shortly after they fixed the bug, I updated my emulator and personal devices to the new Android build, and all worked properly.

As this was clearly an Android build issue, as @jsuarezruiz pointed out, this should be closed.

[South2AK]

@Stedy59 unfortunately I´m still getting the problem.

Visual Studio 17.7.0 Preview 3
net8.0-android

 <Image
     Source="dotnet_bot.png"
     SemanticProperties.Description="Cute dot net bot waving hi to you!"
     HeightRequest="200"
     HorizontalOptions="Center" >



     <Image.Shadow>
         <Shadow Brush="black" Radius="20" Offset="20,20"/>
     </Image.Shadow>
 </Image>

This results in:

[GlacierFox]

@jsuarezruiz I'm getting this problem on my physical Samsung S21 with the latest update. Does this mean anyone using this type of device will have these terrible un-blurred shadows? Works fine on emulator.

[GlacierFox]

Copied over the details from my previous closed post as this issue seems to have been reopened.

Here's a simple repro project I created to showcase the shadow problem:
https://github.com/GlacierFox/MauiShadowError

I've just ran it on my physical Samsung Galaxy S21 and also my Samsung Galaxy Tab A7 Lite and I'm getting the same shadow errors. They both look to be on the same build number as mentioned above. This is what it looks like:

I then ran the exact same project in my API 33 - Android 13 Emulator and it looks fine as you can see below. I've also included an image of the current emulator device details:

I haven't been able to find a work-around for this problem and the shadows look terrible on my physical devices.

I've also just tested the app on a Samsung Galaxy S23 and everything looks fine so it seems it's a problem with the current most recent build of android available for Samsung S21, Galaxy Tab A7/A8 and possibly S22 devices.

[South2AK]

Is there any news on this?

[GlacierFox]

Is there any news on this?

Not that I'm aware of. Still having this problem on both my phone and tablet. Not sure how this hasn't been sorted out yet, it's a major issue.

[jonmdev]

Holy shit. This was first reported OVER ONE YEAR AGO? I found this bug last week and fixed it within 1 hour:

#17886

Perhaps I got lucky as I had just already been inside similar systems of MAUI in the few days prior to understand what was happening for other reasons right before coming across it. So it was obvious to me. But it should have been equally obvious to any Microsoft employee.

All Android scaling to MAUI and back takes place through the FromPixels and ToPixels functions. These are used all over the MAUI Android code. Anyone at Microsoft who wrote any of the MAUI code should know that. So why this was left over a year unfixed is hard to understand.

You can apply the same solution I discuss in that thread through a Behavior or some other function for scaling the radius and offset parameters in Android until they decide to apply it. If anyone is not sure or has trouble, please post back and I can let you know some more, but only in C# (I don't use xaml).

But man, it just goes to what I was saying here:
#17917

MAUI needs help. ☹️

Something like this should have been an easy fix for them. They use the same scaling function all over the internal Android code. Why on earth would something this simple be sitting for a year unsolved?

For example, you can see the opposite Android scaling function FromPixels() here: https://github.com/dotnet/maui/blob/main/src/Core/src/WindowOverlay/WindowOverlay.Android.cs

How could you write that code and not know what ToPixels and FromPixels do?

I am suspecting the people who actually wrote MAUI are long gone.

What is going on with MAUI at Microsoft? ☹️

[jsuarezruiz]

Holy shit. This was first reported OVER ONE YEAR AGO? I found this bug last week and fixed it within 1 hour:

#17886

Perhaps I got lucky as I had just already been inside similar systems of MAUI in the few days prior to understand what was happening for other reasons right before coming across it. So it was obvious to me. But it should have been equally obvious to any Microsoft employee.

All Android scaling to MAUI and back takes place through the FromPixels and ToPixels functions. These are used all over the MAUI Android code. Anyone at Microsoft who wrote any of the MAUI code should know that. So why this was left over a year unfixed is hard to understand.

You can apply the same solution I discuss in that thread through a Behavior or some other function for scaling the radius and offset parameters in Android until they decide to apply it. If anyone is not sure or has trouble, please post back and I can let you know some more, but only in C# (I don't use xaml).

But man, it just goes to what I was saying here: #17917

MAUI needs help. ☹️

Something like this should have been an easy fix for them. They use the same scaling function all over the internal Android code. Why on earth would something this simple be sitting for a year unsolved?

For example, you can see the opposite Android scaling function FromPixels() here: https://github.com/dotnet/maui/blob/main/src/Core/src/WindowOverlay/WindowOverlay.Android.cs

How could you write that code and not know what ToPixels and FromPixels do?

I am suspecting the people who actually wrote MAUI are long gone.

What is going on with MAUI at Microsoft? ☹️

The shadow offset size (scale) is not equal to the radius (the amount of blurring around the edges). Are different issues. This specific issue is related to a bug in Android https://issuetracker.google.com/issues/238769745?pli=1 (BlurMaskFilter is not blurring bitmaps) fixed by Google in the TP1A.220905 build. That is, this issue only occurs in Android 13 with a specific build, neither in previous versions nor in later versions after the fix.

The issues in the repo are prioritized based on different criteria:

• The impact. Labels that indicate a high impact (For example, regression, or layout-grid since the use in almost any app is high). Feedback received, number of comments on the issue, etc.
• Etc.

Unfortunately, there are other issues with a higher score and for that reason this issue is still open. The fix would require changes to the shadow implementation on Android, it is not something trivial, require changes and testing in several devices and versions. I'm going to talk to the team about this specific issue to see if we can increase its priority.

[jonmdev]

Holy shit. This was first reported OVER ONE YEAR AGO? I found this bug last week and fixed it within 1 hour:
#17886
Perhaps I got lucky as I had just already been inside similar systems of MAUI in the few days prior to understand what was happening for other reasons right before coming across it. So it was obvious to me. But it should have been equally obvious to any Microsoft employee.
All Android scaling to MAUI and back takes place through the FromPixels and ToPixels functions. These are used all over the MAUI Android code. Anyone at Microsoft who wrote any of the MAUI code should know that. So why this was left over a year unfixed is hard to understand.
You can apply the same solution I discuss in that thread through a Behavior or some other function for scaling the radius and offset parameters in Android until they decide to apply it. If anyone is not sure or has trouble, please post back and I can let you know some more, but only in C# (I don't use xaml).
But man, it just goes to what I was saying here: #17917
MAUI needs help. ☹️
Something like this should have been an easy fix for them. They use the same scaling function all over the internal Android code. Why on earth would something this simple be sitting for a year unsolved?
For example, you can see the opposite Android scaling function FromPixels() here: https://github.com/dotnet/maui/blob/main/src/Core/src/WindowOverlay/WindowOverlay.Android.cs
How could you write that code and not know what ToPixels and FromPixels do?
I am suspecting the people who actually wrote MAUI are long gone.
What is going on with MAUI at Microsoft? ☹️

The shadow offset size (scale) is not equal to the radius (the amount of blurring around the edges). Are different issues. This specific issue is related to a bug in Android https://issuetracker.google.com/issues/238769745?pli=1 (BlurMaskFilter is not blurring bitmaps) fixed by Google in the TP1A.220905 build. That is, this issue only occurs in Android 13 with a specific build, neither in previous versions nor in later versions after the fix.

The issues in the repo are prioritized based on different criteria:

* The impact.  Labels that indicate a high impact (For example, regression, or layout-grid since the use in almost any app is high). Feedback received, number of comments on the issue, etc.

* Etc.

Unfortunately, there are other issues with a higher score and for that reason this issue is still open. The fix would require changes to the shadow implementation on Android, it is not something trivial, require changes and testing in several devices and versions. I'm going to talk to the team about this specific issue to see if we can increase its priority.

Sorry @jsuarezruiz - I misunderstood.

If that is the case, it is obviously up to you how you manage your product, but if it was me personally, from what you said, specific to the issue in this thread (which is NOT then the same issue I posted about):

If something is a Google/Apple/Windows bug and that OS has fixed the bug on their end I don't think it should be your responsibility to write a code-around for the issue.

It is obviously not your fault and not your issue and it is not our responsibility as developers either. It is up to the user to ensure their OS is up to date and has the basic fix from their provider (Google/Apple/Microsoft).

Of all the issues, I wouldn't waste time coding a workaround for an underlying Android bug that has already been fixed years ago.

If it was me, I would just write a note telling people that and close the issue.

I suspect maybe there are a lot of "open" issues here that could be closed on similar grounds (issue fixed or not relevant for MAUI) and maybe closing more would make it easier to see what the actual existing issue backlog is or prioritize more.

While I have your attention, I see you have moved most of the issues I reported and listed here: #17917 to backlog.

The most critical one is the Editor iOS dysfunction reported here: #17757

Without this working no one can develop anything with user text input beyond 1-2 words for iOS. Do you have any thoughts on the probability of a fix or timeline?

All of these however will reduce any possibility of releasing any basic working app. Any thoughts on the backlog in general? Do you also get the sense that most of these "open" issues are not truly open issues but rather just clutter? Or what are your thoughts?

I am just trying to gauge things for my own planning. Thanks and sorry about the wrong conclusion I drew.

[GlacierFox]

@jonmdev hold up. You've misconstrued an issue and now you're advising the development team to close a critical isssue without a full understanding of that one either (which I had reopened).

While the issue is actually tied to the base android operating system, it's not just a simple case of keeping your operating system up to date. Trust me, as seasoned developers we have tried updating our software haha 🤔

The issue is that Samsung has not compiled the Android build with the fix into their custom build for a range of high end, low end and fairly recent phones and tablets running Android API version 33 specifically and these devices seem to be in security only mode now. (Samsung S21, Galaxy Tab A8, to name a few) So no, you can't just update the device and yes, this requires a work-around for MAUI to be fully functional on these devices.

Thanks for your efforts so far in looking into the issue @jsuarezruiz.

[jsuarezruiz]

Thanks for all the feedback.

@jonmdev #17757 has labels indicating that it is important (p1 label). It has high priority, I can't give you specific dates at this time but it should be in upcoming releases.

@GlacierFox I have reviewed builds from some manufacturers and on some devices with a high user base it is a problem. It is definitely an issue and it is not going to be closed. I just wanted to explain that although @jonmdev mentioned another issue, it is related but not the same. Also to fix this issue in that specific build, the implementation of shadow management would have to be changed (avoid bitmaps and BlurMaskFilter).