From the documentation:
By default, enableEdgeToEdge() makes the system bars transparent, except on 3-button navigation mode where the status bar gets a translucent scrim. The colors of the system icons and the scrim are adjusted based on the system light or dark theme.
We can make the bottom bar transparent. However, the app should then extend to the very bottom of the screen, meaning the buttons will obscure the app's interface. Ideally, we shouldn't place any buttons or other views behind them. In that case, transparency makes sense.
If we want the navigation bar to act as a boundary for the application, we need to give it a color. Looking at various professional applications, it's best if this color matches the color of the application's interface. Black or white are most common, depending on the theme.
Yes, it seems that MIT have already overridden the default with the Primary Colour setting 
Not sure I follow all of this. If you want black or white, you could set PrimaryColor to black or white?
Oh, that's useful. I think you should submit a PR with just that change.
We're still feeling out all the effects of Android's new defaults. I think a bunch of incremental fixes is going to give us more flexibility as user feedback comes in.
I have a fix for percent sizing up, and I'm testing a fix for the soft keyboard overlapping the screen. That should go up by the end of the day, and we hope to put them on ai2 quickly.
I have sent a PR.
Yes, of course. But you'll often encounter apps where the bottom bar is a different color than the top. For example, the top bar is black and the bottom bar is gray.
It would also be useful to have the function of disabling the navigation bar, similarly to the status bar.
Yes, we're discussing what we want to do with the screen/project properties related to Android status bar and navbar. The edge-to-edge enforcement really highlighted the fact that you can hide status bar and not navbar.
We're leery of adding a bunch of Android-specific properties, and iOS doesn't navigate this way. We're brainstorming what we can do with both platforms. Evan has suggested just having an edge-to-edge or full screen property that covers both the status bar and the navbar and iOS ui elements. I'm curious if there are any use cases folks can think of where a user would want to hide status bar but not navbar or vice versa.
I also think, having looked at both threads, that maybe invisible should be an option for coloring the status/nav bars. I'm guessing that is not an option for Android's primary color property, but I haven't looked.
I believe the important thing with hiding status and navigation bars is the ability to swipe them back, otherwise device control within the app is lost.
setSystemBarsBehavior(WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE);
I have working java code for individually hiding bars (not the title) and setting swipeable
If you're interested in submitting a PR, I'd love to see it.
Wouldn't know where to start, can just about make an extension 
@SimpleFunction(description = "Hides or shows the status bar (true to hide, false to show).")
public void HideStatusBar(final boolean hide) {
runOnUiThread(new Runnable() {
@Override
public void run() {
Activity activity = form.getActiveForm();
if (activity == null) {
android.util.Log.e("BarMode", "Activity is null");
return;
}
Window window = activity.getWindow();
if (hide) {
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);
window.getDecorView().setSystemUiVisibility(
View.SYSTEM_UI_FLAG_FULLSCREEN | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);
android.util.Log.d("BarMode", "StatusBar hidden");
} else {
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);
window.getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_VISIBLE);
android.util.Log.d("BarMode", "StatusBar shown");
}
}
});
}
@SimpleFunction(description = "Hides or shows the navigation bar (true to hide, false to show).")
public void HideNavigationBar(final boolean hide) {
runOnUiThread(new Runnable() {
@Override
public void run() {
Activity activity = form.getActiveForm();
if (activity == null) {
android.util.Log.e("BarMode", "Activity is null");
return;
}
Window window = activity.getWindow();
View decorView = window.getDecorView();
if (hide) {
decorView.setSystemUiVisibility(
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION | View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY);
android.util.Log.d("BarMode", "NavigationBar hidden");
} else {
decorView.setSystemUiVisibility(View.SYSTEM_UI_FLAG_VISIBLE);
android.util.Log.d("BarMode", "NavigationBar shown");
}
}
});
}
The second method does not work on Android 15+ if the Navbar has already been colored.
(My approach prevents the Navbar from being colored on Android 15+, so this HideNavbar method also works on Android 15+.)
Ok, I'm not clear if I'm doing something wrong. I tested the Companion going back into last year using Android 11, and I saw this problem with pop-up keyboard overlapping a text field in every case.
It may be different with the compiled version. Here's the test app I used:
ScreenBoundaries.aia (1.5 KB)
I'm trying to figure out if I'm doing the wrong thing, or if this really is different from what you're describing.
Yes, this happens because the Arrangements have fixed values for the height. Try this:
ScreenBoundaries2.aia (1.9 KB)
This problem also occurs/occurred with targetSdkVersion=34. Checked on Android 11 (Pixel 2XL).
Here's the compiled APK with the fix I shared on GitHub. The arrangement must be scrollable for this to work.
Your version of the project works fine on my local server.
But it stops working after I close the keyboard programmatically. I'll have to investigate.
Because the .GotFocus event is no longer triggered. I take a second TB, Width=1px and
So TextBox1.GotFocus is triggered again when clicking in TB.
Well, yes. I had a glitch. You have to remove the focus for the GotFocus event to fire and set the layout height back to -2. The problem doesn't occur if you immediately set the layout height to FillParent in the designer. Then, no additional blocks are needed and everything works automatically.
Yes, but only with a button to hide the keyboard. These are workarounds. But once the fix is implemented on the server, they will no longer be necessary. Unless someone insists on a fixed-height layout, then the fix won't work. The screen must have enough space to accommodate the inset.
