# Safe Area Insets not returned correctly for Android **URL:** \ **Category:** Android\ **Created:** [April 1, 2025, 3:49pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708 "2025-04-01T15:49:54Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![yoogle](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yoogle/32/14955_2.png) [@yoogle](https://forum.juce.com/u/yoogle)\ **Post date:** [April 1, 2025, 3:49pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/1 "2025-04-01T15:49:54Z")
Hi Folks, I am trying to get safe area insets for android phones, so that I can prevent drawing my app under those blocked areas like notches and all. I am using this code which is working fine for iOS devices. ```auto auto safeAreaInsets = juce::Desktop::getInstance().getDisplays().getPrimaryDisplay()->safeAreaInsets; ``` For android, its not giving correct safe area insets. I tried making a native application in Android Studio and its respecting the safe area insets. Here is the following code generated by Android Studio. ```auto import androidx.activity.EdgeToEdge; import androidx.appcompat.app.AppCompatActivity; import androidx.core.graphics.Insets; import androidx.core.view.ViewCompat; import androidx.core.view.WindowInsetsCompat; public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); EdgeToEdge.enable(this); setContentView(R.layout.activity_main); ViewCompat.setOnApplyWindowInsetsListener(findViewById(R.id.main), (v, insets) -> { Insets systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars()); v.setPadding(systemBars.left, systemBars.top, systemBars.right, systemBars.bottom); return insets; }); } } ``` How to implement this things in juce so that it will return correct safe area insets, so that I will draw only in safe area by subtracting this insets from local bounds. ---
**Author:** ![aamf](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/aamf/32/19941_2.png) [@aamf](https://forum.juce.com/u/aamf)\ **Post date:** [April 2, 2025, 4:31pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/2 "2025-04-02T16:31:15Z")
This is very basic functionality which one would expect the framework to handle perfectly. There have been numerous threads since at least 2019 pointing these problems out but there has not been a response from anyone from the JUCE team on any of those threads. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [April 2, 2025, 5:41pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/3 "2025-04-02T17:41:45Z")
This is on my radar. At the moment I’m focusing on MIDI 2.0, but I’m planning to investigate Android safe display areas after that. ---
**Author:** ![aamf](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/aamf/32/19941_2.png) [@aamf](https://forum.juce.com/u/aamf)\ **Post date:** [April 2, 2025, 6:04pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/4 "2025-04-02T18:04:12Z")
That’s great, thank you! ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [June 9, 2025, 12:03pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/5 "2025-06-09T12:03:09Z")
Some updates: We now do a better job of respecting safe screen areas in demo projects generated from PIPs. Such projects should now avoid placing demo content beneath notches and other screen decorations: > We’ve also updated our Android safe-area handling: > > > The goal of this change is to ensure that the safeAreaInsets and > keyboardInsets …members of Display correctly take the current system UI > and screen cutouts into account. > > This change also enables rendering behind the status bar and navigation > bar for JUCE applications. This is in line with the new defaults in > Android 15, where building against the Android SDK 35 will automatically > enable "edge-to-edge" drawing. Enabling this behaviour on older > platforms too provides a more consistent experience. On all Android versions, we’ve switched to displaying content “edge-to-edge”, which in practice means that JUCE apps will always draw behind the status and navigation bars. On Android 15 and above, this behaviour is enforced, and we back-ported it to keep the behaviour as consistent as possible between Android versions. As a result of this change, it’s now extremely important to handle the safeAreaInsets correctly, as it’s now much more likely that content will render behind the system UI if these insets are ignored. Finally, we’ve updated the SidePanel component to avoid areas of the screen that might be obscured. This makes the DemoRunner more usable on iPhones and Androids with screen notches: > > > A major benefit of this change is that the menu in the DemoRunner will > now displ…ay reasonably on mobile devices with notches or other > decorations. ---
**Author:** ![aamf](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/aamf/32/19941_2.png) [@aamf](https://forum.juce.com/u/aamf)\ **Post date:** [June 12, 2025, 8:33pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/6 "2025-06-12T20:33:50Z")
I have tested this today and everything works as expected. Thank you very much! ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [June 12, 2025, 8:36pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/7 "2025-06-12T20:36:38Z")
That’s wonderful to hear! ---
**Author:** ![peteatjuce](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/peteatjuce/32/2347_2.png) [@peteatjuce](https://forum.juce.com/u/peteatjuce)\ **Post date:** [June 24, 2025, 5:43pm UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/8 "2025-06-24T17:43:28Z")
Weirdly, when I just tried evaluating this when looking at the JUCE 8 develop tip, it worked fine for my test when using an SDK 36 emulator, but displayed my app with a tiny window when using an emulator for SDK 35 or SDK 34 (the oldest I went back to). If anybody else spots this behaviour, do please let me know! ---
**Author:** ![peteatjuce](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/peteatjuce/32/2347_2.png) [@peteatjuce](https://forum.juce.com/u/peteatjuce)\ **Post date:** [June 27, 2025, 8:43am UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/9 "2025-06-27T08:43:00Z")
I decided to look again at this, and found the “tiny window” problem was due to my not calling setKioskModeComponent for the main window component. No such issue for SDK 36 emulators! ---
**Author:** ![yoogle](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yoogle/32/14955_2.png) [@yoogle](https://forum.juce.com/u/yoogle)\ **Post date:** [May 5, 2026, 10:53am UTC](https://forum.juce.com/t/safe-area-insets-not-returned-correctly-for-android/65708/10 "2026-05-05T10:53:18Z")
![Screen Recording 2026-05-05 at 4.12.40 PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/6/b/6bb14a3deaa37140b1b5490e24d0913917b45f67.gif) I am encountering a critical issue specifically on devices running Android 11. After launching the app, the UI becomes completely unresponsive—no interactions are possible, and the app cannot even be closed using standard system controls. The only way to terminate the app is by restarting the device. This issue does not occur on other Android versions. For example, the app functions correctly on a device running Android 16. I have reproduced the problem both on an Android 11 emulator and a physical device running the same version. Notably, this behavior was not present in previous JUCE versions, which suggests a possible regression or compatibility issue introduced in newer updates. This is a severe problem, as it effectively locks the user’s device and creates a denial-of-service–like experience. I would appreciate guidance on potential causes or solutions to resolve this issue.