Viewport/elements resize when virtual keyboard appears

Help
1

Godot Version

4.5.1

Question

I am developing a mobile app, a meditation timer. I’m testing on Android. The main screen of the game has a place where the user can enter a time. However, when the virtual keyboard appears, the viewport and all the elements on the screen change size. They shrink because they think the viewport has gotten smaller, because the keyboard takes some space, and then they expand when the keyboard is gone.

I have tried:

  • Setting android:windowSoftInputMode="adjustNothing" and android:configChanges="layoutDirection|locale|orientation|keyboardHidden|screenSize|smallestScreenSize|density|keyboard|navigation|screenLayout|uiMode" in AndroidManifest.xml. Although I’ve read that sometimes AndroidManifest.xml is overwritten, I think it is working because I changed the windowSoftInputMode to pan, and the screen does seem to pan when the keyboard appears (but it’s actually worse than the other setting).

  • Using absolute positions rather than anchors.

  • Forcing the viewport back to its original size with the on_viewport_size_changed signal and get_window().size = initial_size and the Window.size property. (Aside: Why is there no Viewport.size or set_size()`?)

Here’s a video of the problem (ignore the poor resolution, I saved the video at a really small file size—the expand/contract of the graphical elements is what matters):

2

Well, I’ve verified that, yes, the issue is the viewport is resizing when the keyboard pops up. I’m designing at a small resolution (360x640, a 16:9 resolution) as one does, and then stretching out maintaining aspect ratio by width. That’s normal for mobile apps/games; you can’t develop for a set resolution. (I probably should be developing for 20:9 or 19:9, particularly since my phone is 20:9 and nobody else will ever use this app. But that’s a different discussion.)

Anyhow, I can’t figure out any way to either:

  1. muscle the viewport to retain its original resolution prior to the keyboard popping up, allowing things to get covered up or whatever instead of helping me out by scaling (smaller) to accommodate the temporary new, smaller screen while the keyboard is up and then scaling again (bigger) when the keyboard disappears; or
  2. make all the elements (i.e., the lotus flower and menu button) maintain their position despite the change in viewport size. I thought that was the whole point of setting a position rather than anchors, but I guess not, because it doesn’t work. I suppose this is because the absolute position is set by the 0, 0 of the viewport. But even if I could fix the position, that’s not really the issue, the problem is the change in scaling/stretching.

There’s only one godotengine issue on Github that seems relevant, “Virtual keyboard height is wrong when making navigation bar permanently visible #86663” but the concern there seemed to be arranging elements outside of the keyboard. One person sets android:windowSoftInputMode="adjustResize in their Android manifest, which is the opposite of what I want; and I set that to adjustNothing which seems to be ignored (although my manifest is used, if I wanted to pan or resize, those work). Another person sets to use the safe areas, which also is irrelevant to what I want; I did try setting my main node, a Control, to be so small that it shouldn’t need to be adjusted when I lose space with the keyboard, but that didn’t work either.

I tried LLMs, of course—I usually use Claude Sonnet 4.5, for learning and a rubber duck, and an alternative to forums and Discord where I just get silence 90% of the time so why not lean on an error-prone but at least responsive entity—and they went through some hilariously bad solutions that were ineffective at best and horribly broken at worst (turning my app into a tiny, unusable 360x640 rectangle at 0, 0 of the real resolution wasn’t helpful—and it still blooped when pulling up the keyboard).

The LLM finally gave up. Its last, sage words to me:

But here’s the key insight: Is the resize disruption actually a problem? You’re just typing 1-2 digits and hitting enter. The visual shift happens for maybe 2 seconds. Is that worth all this complexity?

Thanks, Claude. To be fair, I’ve seen this issue in other apps I’ve used, so I guess most people do give up. It appears to be a pain point across Android dev platforms, web-based, other game engines, and otherwise. I could make a custom numpad pop up, but it would cover the graphics, so what’s the point?

What I’ll actually do is fade out and hide the lotus and menu button images while the user enters a new time. Hey, focusing on one thing at a time, that’s the point of the app?