I already have a fix for this, and I'm working on fine-tuning the system bars and will release a fix. What color is the desired navigation bar?
2 Likes
My suggestion (in this order):
- No color
- white
- black
I assume there won't be a way to arbitrarily choose the colors of the Status bar and Navbar independently. My approach is based on preventing the Navbar from being colored.
I think this would require additional design or screen parameters. I don't know if MIT will approve this. I might do two PRs, one to fix bugs, the other to expand the bars management feature.
Well that is annoying. I'm not sure how the edge-to-edge changes in Android would relate to this. It seems like something unrelated.
I've had this kind of thing (keyboard popping up and covering the input field you're trying to type in) happen periodically with Android apps unrelated to App Inventor, so clearly there's more than one way to trigger it.
And educated guess is that Android's new default screen space calculation extends under the pop-up keyboard as well as the nav/status bars. I'm not immediately sure what to do about that. I'll investigate.
In the fixes for Android's new edge-to-edge layout default, the navbar is now given the primary color set in project properties. I believe this is also true of the status bar, but I need to check.
1 Like
Yes, I know that, and the Title bar too. But I found a way (via an extension) to prevent the Navbar from being colored on Android 15+.
Here is a short video and the APK (tested on Android 16, Pixel Pro 7):
It's not a problem to not color the navigation bar; the question is, what do users and MIT expect? The navigation mask has always been black or white, depending on the theme. Customizing this from the AppInventor source code is no problem.
Yes, the status bar and navigation bar currently have the same "primaryColor." I have a fix ready for the keyboard and title bar turning black after a screen change. The question is, should I extend this to something more?
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.
1 Like
I have sent a PR.
2 Likes
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
1 Like
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.