Application covers Android Buttons

Android
1

In version 8.0.10

setFullScreen (true)

covers Android buttons.
Same result in development version.

2

The expected behaviour of setFullScreen is that the application fills as much space as possible, including drawing behind the navigation bar and status bar. You can query the Display safe area to find out which areas should be reserved for the system UI.

  • Do you mean that the buttons aren’t visible at all, or that they are drawn over the JUCE application? Can you provide a screenshot?
  • Do you see the same behaviour in any of the example projects from the JUCE repository?
  • What devices have you tested?
  • What Android versions have you tested?
3

JUCE draws over the buttons

setFullScreen
setFullScreen720×1560 90.9 KB

4

Is there a function setFullSafeArea () instead of setFullScreen() ?
We have tested with 2 devices : Samsung A11 / Android 12 and Samsung S25 / Android 15

Did not test JUCE repository.

With version 8.0.8 and 8.0.7 everything is OK

5

setFullScreen(true) and Desktop::getInstance().setKioskModeComponent (this, true) have same functionality.

6

In your screenshot, I can still see the Android buttons (back button in the bottom right, circle button in the middle) and statusbar items (wireless reception, date/time) so it looks like JUCE is drawing behind the system UI, which is the expected behaviour.

No, there’s no such function. This is deliberate - the application should still draw a background in the ‘unsafe’ area to ensure a seamless appearance.

A simple way to achieve this is to separate your main content component from the top-level component. The top-level component is then responsible for drawing a background that fills the entire screen area, including the area behind the status and navigation bars. The top-level component should also position the content component so that it doesn’t overlap with the status/navigation bars.

This is the approach we take in the DemoRunner application bundled with JUCE. The content component is positioned in MainComponent::resized(), shown here:

These functions should have slightly different behaviour, as follows:

setFullScreen resizes the component so that it fills the largest possible area. This is generally the full screen area, but may be smaller, for example if split-screen mode is enabled. setFullScreen does not hide the navigation and status bars.

setKioskModeComponent additionally hides the navigation and status bars, and requires the user to swipe from the top/bottom of the screen in order to reveal the system UI. In this case, the ‘safe area’ no longer includes the navigation and status bars (because they’re not shown) but may still include space for a notch or other display cutout.

If this doesn’t match the behaviour you’re seeing, please let us know and we can investigate. Please provide as much detail as possible - we need to know at least the JUCE version, the Android version, and whether the issue is present in the JUCE DemoRunner, before we can investigate.

7

Hi reuk,

Thanks for detailed reply.

uygulama_ana_sayfasi_d
uygulama_ana_sayfasi_d720×1560 86.2 KB

uygulama_ana_sayfasi_y
uygulama_ana_sayfasi_y1560×720 121 KB

Using safeBounds resolved almost everything.

But after opening a custom dialog and closing it , safeBounds being smaller.

uygulama_open_dialog
uygulama_open_dialog720×1560 143 KB

uygulama_yeni_d
uygulama_yeni_d720×1560 129 KB

uygulama_yeni_y
uygulama_yeni_y1560×720 158 KB

We have also tested dialog windows with “DialogsDemo” and “WindowsDemo” examples .
safeArea remains same after closing dialog window.

Almost everything are same with examples. Do you have any idea ?

Regards

8

On iOS safeArea remains same after opening and closing custom dialog window.

It’s an Android issue

9

It seems that adding any window to the desktop messes up the safe areas on Android.

There’s a similar problem with the MIDI Bluetooth pairing dialog. If it is added to the main component instead of the desktop everything is fine.

10

To add to main_component “launch_options.componentToCentreAround = main_component;” must be enough.

Or not ?

Result of checking in Dialog with isOnDesktop : 0

11

It’s difficult to guess at the problem without being able to reproduce the problem locally.

Unfortunately I can’t currently produce the same behaviour in a JUCE example project, so it’s difficult to guess at the problem. From the screenshots, it looks like the system is applying the insets to the top level component as well as forwarding those insets. So, maybe we need to put the window back into edge-to-edge mode after closing a top-level window. I can’t easily test this theory without first triggering the problem, though.

It would be helpful to know:

  • What minSdkVersion and targetSdkVersion are you using? You can find these in the build.gradle for your app. Are these values the same between your app project and the JUCE examples that you tested?
  • What is the Android version of the device that you used to take the screenshots? Do you see the same behaviour on both Android 12 and Android 15? Do you see the same thing in the Android emulator?
12

minSdkVersion 24 , targetSdkVersion 35
With Android 12 and Android 15 behaviour does not change.

Here is a workaround. I hope it may give you some clue.

// Starting Dialog
#if defined (JUCE_ANDROID)
    dw->enterModalState (true, callback, false);
#else
    dw->enterModalState (true, callback, true);
#endif

// Closing Dialog
m_close_button.onClick = [this] {
    if (DialogWindow* dw = contentComponent->findParentComponentOfClass<DialogWindow>())
        #if defined (JUCE_ANDROID)
            dw->setVisible(false);
            this->~DECONSTRUCTOR();
        #endif
        dw->exitModalState (0);
    }
};