[Android] VisibleBoundsPadding.PaddingMask.Top does not always work as intended

[takla21]

Current behavior

When I removed the status bar by adding those 4 lines in the style.xml

<item name="android:windowTranslucentStatus">false</item>
<item name="android:windowTranslucentNavigation">true</item>
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
<item name="android:statusBarColor">@android:color/transparent</item>

Applying VisibleBoundsPadding.PaddingMask.Top on top of my xaml, it won't give enough space for the status bar and notch (if available)

Android

*See workaround for expected result

Expected behavior

Expected result and Actual result should be mostly aligned vertically.

iOS

How to reproduce it (as minimally and precisely as possible)

Download StatusBarPaddingMask.zip
Deploy on Android

Workaround

To achieve similar result, I am able to retrieve the actual status bar height with StatusBar.GetForCurrentView().OccludedRect.Height. I am wondering if this should actually be used to calculate VisibleBoundsPadding.PaddingMask.Top

Environment

Nuget Package:

• Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia
• Uno.WinUI / Uno.WinUI.WebAssembly / Uno.WinUI.Skia
• Uno.SourceGenerationTasks
• Uno.UI.RemoteControl / Uno.WinUI.RemoteControl
• Other:

Nuget Package Version(s): 3.9.0-dev.6

Affected platform(s):

• iOS
• Android
• WebAssembly
• WebAssembly renderers for Xamarin.Forms
• macOS
• Skia
  • WPF
  • GTK (Linux)
  • Tizen
• Windows
• Build tasks
• Solution Templates

IDE:

• Visual Studio 2017 (version: )
• Visual Studio 2019 (version: 16.8.4)
• Visual Studio for Mac (version: )
• Rider Windows (version: )
• Rider macOS (version: )
• Visual Studio Code (version: )

Relevant plugins:

• Resharper (version: )

Anything else we need to know?

[jeromelaban]

The computation is supposed to use the status bar size to set the ApplicationView.VisibleBounds property:

uno/src/Uno.UI/UI/Xaml/Window.Android.cs

Lines 156 to 159 in d59985f

	var visibleBounds = CalculateVisibleBounds(statusBarSizeExcluded);
	var trueVisibleBounds = CalculateVisibleBounds(statusBarSize);
	ApplicationView.GetForCurrentView()?.SetVisibleBounds(visibleBounds);
	ApplicationView.GetForCurrentView()?.SetTrueVisibleBounds(trueVisibleBounds);

Could be the computation is done too early or not using the same content from occluded area.

[Youssef1313]

My best guess is that what stated in this comment isn't actually working:

uno/src/Uno.UI/UI/Xaml/Window.Android.cs

Lines 91 to 92 in 0c075f5

	// The real metrics excluded the StatusBar only if it is plain.
	// We want to subtract it if it is translucent. Otherwise, it will be like we subtract it twice.

Nothing gets subtracted when android:windowTranslucentStatus is false.

@davidjohnoliver Since you worked on a similar issue in #4352, would you be able to help where/how to investigate?

[davidjohnoliver]

@Youssef1313 This is the 'where', indeed. :)

The point of the comment, IIRC, is that the native metrics returned by Android are different depending if the status bar is opaque or translucent. Accordingly we don't to 'double dip' in certain parts of the math by subtracting it twice. But clearly if the VisibleBounds is not taking the translucent status bar into account then the logic is faulty somewhere.

[rafaelrmoukc]

Start work on that issue, error still repro.

[rafaelrmoukc]

After some study i got that:

Android has a "fitsSystemWindows" attr to sets the padding to your view (if needed) to prevent your content from being obscured by the system status bar or navigation bar.

What realy need to do isn't change the padding manually, but set fitsSystemWindows=true at the Layouts. Only problem is the fitsSystemWindows not work with some Layouts (eg.: FrameLayout) and need a override like that https://proandroiddev.com/draw-under-status-bar-like-a-pro-db38cfff2870

@jeromelaban what you think about?

Just a moment...

[jeromelaban]

@rafaelrmoukc the issue here is about the computations made by the Window.VisibleBounds property. I would not be surprised that we're not computing the size of the status bar here:

uno/src/Uno.UI/UI/Xaml/Window.Android.cs

Lines 105 to 110 in d59985f

	var statusBarSizeExcluded = IsStatusBarTranslucent() ?
	// The real metrics excluded the StatusBar only if it is plain.
	// We want to subtract it if it is translucent. Otherwise, it will be like we subtract it twice.
	statusBarSize :
	0;
	var navigationBarSizeExcluded = GetLogicalNavigationBarSizeExcluded();

When android:windowDrawsSystemBarBackgrounds is set to true.

Can you validate the value of that property?

[rafaelrmoukc]

@jeromelaban of course, I will do that now, thanks for the help.

[rafaelrmoukc]

@jeromelaban only to make a test I set the statusBarSizeExcluded to 100, and receive the same result at GetVisualBoundsLegacy (no changes at app).

Without set to 100, the size is 24 (right size), and not change (same result).

See below.

I think the problem isn't on computing the size, but when apply that. Any idea?

@iury-kc see that.

[rafaelrmoukc]

I change the trueVisibleBounds too, and got same result.

[jeromelaban]

interesting. So the CalculateVisibleBounds method is not doing the right computation, maybe because of this line?

uno/src/Uno.UI/UI/Xaml/Window.Android.cs

Line 162 in 73247e5

var topHeightExcluded = Math.Max(Insets.Top, excludedStatusBarHeight);

[rafaelrmoukc]

I Will check that nos, thanks. Em terça-feira, 7 de junho de 2022, Jérôme Laban ***@***.***> escreveu:

…

interesting. So the CalculateVisibleBounds method is not doing the right computation, maybe because of this line? https://github.com/unoplatform/uno/blob/73247e5b154985abe84472157ea96c 80762cb6e7/src/Uno.UI/UI/Xaml/Window.Android.cs#L162 — Reply to this email directly, view it on GitHub <#6218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZNT4LEDYW775RF57SHJFC3VN46CVANCNFSM46NCEQKQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rafaelrmoukc]

@jeromelaban I set 100 on both vars, topHeightExcluded and statusBarSizeExcluded, but nothing change on screen. Like i said before, the values of Bound are rigth, but the values isn't applied at the view, see the screenshot:

If u check the workaround @takla21 do, he change the padding of Layout (grid), not of the Window (Activity?)

private static void OnIsEnabledChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args) { #if !WINDOWS_UWP var baseElement = (Grid)sender; var statusBar = StatusBar.GetForCurrentView().OccludedRect; var thickness = new Thickness( baseElement.Padding.Left, baseElement.Padding.Top + (int)statusBar.Height, baseElement.Padding.Right, baseElement.Padding.Bottom); baseElement.Padding = thickness; #endif }

What u think about?

See @iury-kc

[jeromelaban]

The window is not supposed to have a padding. The configuration of the app is done in such a way that the entirety of the screen is supposed to be used.

If the VisibleBounds is correct, then it may be an issue with the VisibleBoundsPadding itself:

uno/src/Uno.UI/Behaviors/VisibleBoundsPadding.cs

Line 214 in 489be09

private void UpdatePadding()

[rafaelrmoukc]

I will check that, thank you for the help @jeromelaban !

[rafaelrmoukc]

@jeromelaban After update Uno Source to last version the issue stop to occur, screenshots bellow on API <= 29 (simulator) and API > 29 (device)

@iury-kc

This can be close.

[jeromelaban]

Interesting! Would you be able to find which version of Uno fixed this? Which one were you using and which one are you using now? It'll be interesting to find which change fixed this, as there may be related issues that would benefit from knowing what happened. Thanks!

[rafaelrmoukc]

@jeromelaban Before i have 4.4.0-dev.164 now 4.4.0-dev.205, I can check one by one if u need. Do you?

[jeromelaban]

Yes please, there won't be that many packages to validate, thanks!

[rafaelrmoukc]

Of course, thanks!

[ghost]

Nice! There are many issues related to this behavior, specially with Android.
For example:
#6216

Probably, it will help/guide to close most of them.

[rafaelrmoukc]

@jeromelaban after the PR #8960 the problem disappear.

What happen before #8960: Window class compute padding, but the UpdatePadding never fire

After #8960: Window class compute padding, the UpdatePadding fire

I Will test #6216 to check if that is solved too.

[jeromelaban]

It's very curious, I do not see how #8960 could have had an impact on this behavior... it seems completely unrelated to layout management.

[rafaelrmoukc]

@jeromelaban @iury-kc sorry, after a double check i add activity.Window.Attributes.Flags.HasFlag(WindowManagerFlags.DrawsSystemBarBackgrounds) on the code before update and on update source code that stay. That check solve the problem

Test 6216 and if both are solve i will implement TESTS

[Lee31416]

I still get this issue on uno "5.6.20" which is the latest when I updated today. I have a sample but for some reason I can't paste it here, but Kevin's issue still holds true with the android translucent flag and his workaround also still works althought it's not ideal

[jeromelaban]

@Lee31416 would you be able to try with SafeArea instead?

[Lee31416]

@jeromelaban I already tried that and most other workaround we had done before like VisibleBoundsPaddingMask, SafeArea.insets, the safearea control and nothing seems to work

[Lee31416]

@jeromelaban which version of uno will contain the fix ?

[jeromelaban]

@Lee31416 it should be an upcoming 5.6 service release, but there's an additional update coming in #19501