Samsung Galaxy S20+ frequently does not report safe area correctly

[loftafi]

On my Samsung Galaxy device, about 10% of the time, the safe area is reported correctly on startup. This has already been described in another issue:

#10375

The ticket is closed suggesting that sometimes there is a short delay before the safe area becomes available.

Using SDL_AddTimer to check the safe area ever 0.5s post startup, for a period of about 15 seconds, often the safe area is still never reported correctly.

Could there be a bug which causes the correct safe area to not be reported until the device is rotated? Is the first failing initial safe area call caching its result, preventing fetching the safe area again until the screen is rotated?

[slouken]

@Packetdancer, can you take a look at this?

[Packetdancer]

@loftafi - Is the affected device a Galaxy S20 as on the other ticket, or a different Galaxy device?

(I ask because I've seen S20+ used both to mean "the Galaxy S20 Plus" and to mean "a Galaxy device that is the S20 or any device released after it.")

[Packetdancer]

I've tested with a Galaxy S21 and Galaxy Tab A7, and both seem to work correctly -- I get a correct safe area on startup, and it persists whenever I rotate. For instance, with the S21, I start in portrait, I rotate to landscape, and then rotate back. The test app prints out the safe area on startup, and then any time after that it changes, and I get:

SAFE: upper left 0,145 -> lower right 1440,3020 (startup)
SAFE: upper left 100,90 -> lower right 1260,3200
SAFE: upper left 100,90 -> lower right 3020,1440
SAFE: upper left 0,145 -> lower right 3200,1260
SAFE: upper left 0,145 -> lower right 1440,3020

Can you elaborate on what you're seeing as the incorrect safe area?

[loftafi]

Thanks for checking. I am an iOS user normally, I purchased two second hand androids for testing. The behaviour I am describing is on what the device reports itself as:

Samsung Galaxy S20+ SM-G9860, running One UI, Android Version 13, Kernel 4.19.113

I suppose if this behaviour can not be replicated on the S21 model, perhaps the odd behaviour is only occurring on S20 and/or Android 13. That is I suppose good news, as it means it's only older Samsungs that might be impacted. (Perhaps due to the S20 being slower as suggested in the original issue/ticket?)

The exact logs from my app are pasted on the original issue here:

#10375 (comment)

The logs show the app starting, and the safe area being reported as basically 0,0,0,0, then after rotation the safe area gets correct/actual safe area numbers. i.e On initial startup, you see this,

2025-08-27 01:37:27.318  SDL_GetWindowSizeInPixels width=1080 height=2400
2025-08-27 01:37:27.318  SDL_GetWindowSafeArea: 0x0 1080x2400

Timer is triggered to check the safe area again (repeatedly)

2025-08-27 01:37:27.375  android safe area timer hack interval=497
2025-08-27 01:37:27.375  updateScreenMetrics (called by timer)
2025-08-27 01:37:27.375  SDL_GetWindowSizeInPixels width=1080 height=2400
2025-08-27 01:37:27.375  SDL_GetWindowSafeArea: 0x0 1080x2400

Then at the bottom of the log you see a screen rotation message, and now screen metrics are correct:

2025-08-27 01:37:50.015  updateScreenMetrics (called by SDL_EVENT_WINDOW_RESIZED)
2025-08-27 01:37:50.015  SDL_GetWindowSizeInPixels width=2400 height=1080
2025-08-27 01:37:50.015  window resized 384x854 (scale=2.8125) => 854x384 (2.8125) (scale=2.8125) mouse_scale=2.8125 user_scale=1
2025-08-27 01:37:50.015  SDL_GetWindowSafeArea: 73x68 2192x1012
2025-08-27 01:37:50.015  safe area changed: 73x68 2192x1012
2025-08-27 01:37:50.015  safe area updated: 0 0 0 0 -=> 26 24 0 0
2025-08-27 01:37:50.015  updateScreenMetrics (called by SDL_EVENT_WINDOW_PIXEL_SIZE_CHANGED)
2025-08-27 01:37:50.015  SDL_GetWindowSizeInPixels width=2400 height=1080
2025-08-27 01:37:50.015  SDL_GetWindowSafeArea: 73x68 2192x1012

I need to see if I can find someone with a Samsung S21 for comparison. (Its hard because most people I know use Apple)