Software Android buttons overlap the window

CaptainFlint commented

2025-12-05 08:03:54 +01:00

I have a TCL L7 smartphone which doesn't have hardware buttons for the default Android actions Back, Home, Apps. Instead it reserves a part of the screen for these buttons. When I run EasyEUICC, its windows doesn't take into account that part of the screen is inaccessible, and puts the contents underneath that system bar, making that part of the window barely readable and unreachable for interaction.

When it's just a text, it's more or less a minor inconvenience. However, when I tried to add a profile to my eSIM, on the first screen the Next button is completely hidden under that system area, and I cannot press it. Luckily, when I rotate the screen, the buttons bar remains where it was, so the application buttons become accessible. But still, this is quite a significant UI issue.

I'm using EasyEUICC 1.4.0-unpriv, Android version 10.

Here is the screenshot. You can see that the Back and Next buttons are barely visible through the bottom bar:

I have a TCL L7 smartphone which doesn't have hardware buttons for the default Android actions Back, Home, Apps. Instead it reserves a part of the screen for these buttons. When I run EasyEUICC, its windows doesn't take into account that part of the screen is inaccessible, and puts the contents underneath that system bar, making that part of the window barely readable and unreachable for interaction. When it's just a text, it's more or less a minor inconvenience. However, when I tried to add a profile to my eSIM, on the first screen the Next button is completely hidden under that system area, and I cannot press it. Luckily, when I rotate the screen, the buttons bar remains where it was, so the application buttons become accessible. But still, this is quite a significant UI issue. I'm using EasyEUICC 1.4.0-unpriv, Android version 10. Here is the screenshot. You can see that the Back and Next buttons are barely visible through the bottom bar: ![image](/attachments/5f81317f-effd-4e8b-8697-26a5f51d0c1d)

image.png

44 KiB

septs commented

2025-12-05 11:26:25 +01:00

Collaborator

android 16 on pixel 8a, this problem cannot be reproduced.

If possible, please tell me how to fix it.

android 16 on pixel 8a, this problem cannot be reproduced. If possible, please tell me how to fix it.

CaptainFlint commented

2025-12-05 16:54:17 +01:00

Author

Sorry, I'm not an Android developer, and know next to nothing about how these things are controlled in the code. :-( It's the first app I have on this phone that has this issue. All the other apps behave in one of the following ways:

reduce their window area and avoid overlapping completely (as if the screen size is smaller than it really is); example: AlReader;
use the whole screen area, but make the button bar area background transparent, and use that area only for showing more of the background; example: Organic Maps when displaying the map screen: the map occupies all the screen space, including the button bar, but the actual application's controls are shifted upwards and do not overlapp with the Android system buttons;
use the whole screen area, without making the bar transparent; the text/controls are visible below this bar (just like in EasyEUICC), but this area is not considered the actual edge of the screen: when I scroll upwards, all the text/controls keep scrolling until they are completely outside, fully visible/reachable. Example: various Organic Maps dialogs, like Settings screen.

The same Organic Maps, started on a smartphone with hardware buttons, displays the control buttons closer to the screen edge; so it's not just a lucky coincidence, but an intentional adjustment.

Here are a few illustrative screenshots:

AlReader, main reading screen: the screen area used by the app is cut off at the system buttons bar
Organic Maps, map view on TLC L7 with software buttons
Organic Maps, map view on Unihertz Atom L with hardware buttons (you can see how the app's buttons are located lower, closer to the real edge of the screen)
Organic Maps, the Add Map dialog on TLC L7, partially scrolled (overlapping is clearly visible)
The same dialog, but fully scrolled to the end (the final entry fully emerged from under the system buttons bar)

Sorry, I'm not an Android developer, and know next to nothing about how these things are controlled in the code. :-( It's the first app I have on this phone that has this issue. All the other apps behave in one of the following ways: - reduce their window area and avoid overlapping completely (as if the screen size is smaller than it really is); example: AlReader; - use the whole screen area, but make the button bar area background transparent, and use that area only for showing more of the background; example: Organic Maps when displaying the map screen: the map occupies all the screen space, including the button bar, but the actual application's controls are shifted upwards and do not overlapp with the Android system buttons; - use the whole screen area, without making the bar transparent; the text/controls are visible below this bar (just like in EasyEUICC), but this area is not considered the actual edge of the screen: when I scroll upwards, all the text/controls keep scrolling until they are completely outside, fully visible/reachable. Example: various Organic Maps dialogs, like Settings screen. The same Organic Maps, started on a smartphone with hardware buttons, displays the control buttons closer to the screen edge; so it's not just a lucky coincidence, but an intentional adjustment. Here are a few illustrative screenshots: 1. AlReader, main reading screen: the screen area used by the app is cut off at the system buttons bar 2. Organic Maps, map view on TLC L7 with software buttons 3. Organic Maps, map view on Unihertz Atom L with hardware buttons (you can see how the app's buttons are located lower, closer to the real edge of the screen) 4. Organic Maps, the Add Map dialog on TLC L7, partially scrolled (overlapping is clearly visible) 5. The same dialog, but fully scrolled to the end (the final entry fully emerged from under the system buttons bar) ![image](/attachments/e3b8d1f7-db52-4d14-9ff9-18d16f8b3721) ![image](/attachments/f5ba716e-f13b-46b4-bf45-d0a780844e4d) ![image](/attachments/4d12ae8a-7f0f-4472-afba-e63603654a1e) ![image](/attachments/2782050c-8842-4912-a062-92f3798f3c25) ![image](/attachments/8d7317ee-841e-48d4-bce6-36381219d18d)

image.png

269 KiB

image.png

209 KiB

image.png

86 KiB

image.png

82 KiB

image.png

386 KiB

PeterCxy commented

2025-12-08 01:33:55 +01:00

Owner

I know this happens occasionally on some OEMs, but unfortunately without a testing device I don't have a good way to debug this. On AOSP this behaves correctly and I can't seem to reproduce it going back a few versions on AOSP.

The "intentional adjustment" you mentioned already exists in Open/EasyEUICC, and it works on AOSP, so it is something about your OEM that's returning the wrong value for these insets.

Waiting for anyone who has a device with this issue and knows about Android development for a fix.

I know this happens occasionally on some OEMs, but unfortunately without a testing device I don't have a good way to debug this. On AOSP this behaves correctly and I can't seem to reproduce it going back a few versions on AOSP. The "intentional adjustment" you mentioned already exists in Open/EasyEUICC, and it works on AOSP, so it is something about your OEM that's returning the wrong value for these insets. Waiting for anyone who has a device with this issue _and_ knows about Android development for a fix.

PeterCxy commented

2025-12-08 02:02:50 +01:00

Owner

@CaptainFlint Are you able to test the latest commit and see if that fixes your issue? If not, I'm really out of ideas what might be happening on these OEMs.

(You can get a signed APK from Actions, it's currently building as I am writing this but you should see an APK by the time you see this comment)

@CaptainFlint Are you able to test the latest commit and see if that fixes your issue? If not, I'm really out of ideas what might be happening on these OEMs. (You can get a signed APK from Actions, it's currently building as I am writing this but you should see an APK by the time you see this comment)

PeterCxy commented

2025-12-08 02:05:28 +01:00

Owner

https://github.com/flutter/flutter/issues/168635 similar issue with Flutter on some OEMs (like Samsung), not sure if/how they ever fixed it, but it really does look like something is weird about how these OEMs report window insets.

PeterCxy commented

2025-12-08 02:23:52 +01:00

Owner

Window insets might just be broken pre Android 11

May be related as well? https://github.com/streetcomplete/StreetComplete/issues/6030 Window insets might just be broken pre Android 11

PeterCxy commented

2025-12-08 02:38:36 +01:00

Owner

Actually, reading the link above gave me another idea -- I've pushed another potential fix, @CaptainFlint are you able to test?

CaptainFlint commented

2025-12-08 08:41:47 +01:00

Author

@PeterCxy I installed the app-unpriv-debug.apk from activity 473 (Commit b7fc164a3f), and it did fix it. In this version the adding profile dialog has the Back and Next buttons above the system buttons area, fully visible and accessible. Although they are drawn on the same background color as the system area, so it looks like it's a part of Android instead of the app, but that's a minor cosmetic issue.

Thanks for the work and effort, really appreciate it!

The screenshot of the test version:

@PeterCxy I installed the app-unpriv-debug.apk from activity 473 (Commit b7fc164a3f), and it did fix it. In this version the adding profile dialog has the Back and Next buttons above the system buttons area, fully visible and accessible. Although they are drawn on the same background color as the system area, so it looks like it's a part of Android instead of the app, but that's a minor cosmetic issue. Thanks for the work and effort, really appreciate it! The screenshot of the test version: ![image](/attachments/ea52a68f-833e-4aae-aec9-e44b8cac5282)

image.png

56 KiB

septs commented

2025-12-08 11:44:46 +01:00

Collaborator

resolved

septs closed this issue

2025-12-08 11:44:46 +01:00

CaptainFlint commented

2025-12-08 14:47:41 +01:00

Author

Just in case, only the screenshotted screen was fixed in that build. All the other ones still have the same behavior with overlapping under the buttons area (e.g. the main screen with the big "+" button; the Settings dialog, etc.). I didn't mention it, because I considered it to be just a test, with only that specific dialog changed.

PeterCxy commented

2025-12-08 15:01:25 +01:00

Owner

Yes, I didn't fix the rest because I'd like to confirm that it works -- I'll go fix the rest next since I now know what's going on.

👍 1

Rows
Columns

Software Android buttons overlap the window #276