This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Handling system UI visibility (androidFullscreen.patch, text/plain, 2017-11-19 01:43:09 +0000, 3757 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Android (All), x86

Comments on the original bug report:

On 2017-11-02 22:45:22 +0000, Diego wrote:

With the newest commit cf6fe791a6ee the Android Studio project would not compile until I set the targetSdkVersion to 19 because SYSTEM_UI_FLAG_IMMERSIVE_STICKY was unresolved.

On 2017-11-02 23:04:25 +0000, Diego wrote:

I also had to set the compileSdkVersion to 19

On 2017-11-03 08:47:41 +0000, Sylvain wrote:

Indeed commit https://hg.libsdl.org/SDL/rev/cf6fe791a6ee
see also bug 3445

On 2017-11-03 08:54:33 +0000, Sylvain wrote:

Copy paste the comment:

• Per SDL_androidwindow.c, Android will only ever have one window, and that window
• is always flagged SDL_WINDOW_FULLSCREEN. Let's treat it as an immersive fullscreen
• window for Android UI purposes, as a result.

I think there is an issue because, on device (Nexus 10) that have soft buttons. Activating the immersive mode, sticky or not, with this patch:

• make the app use the totality of the screen (ok, make sense).
• then it draws the navigations (back, home, overview) on top of it, but it never hides like we could expect with a timeout.

On 2017-11-05 05:07:50 +0000, Sam Lantinga wrote:

I'm going to iterate on this, thanks!

On 2017-11-12 17:23:31 +0000, AriaMoKr wrote:

(In reply to Diego from comment # 1)

I also had to set the compileSdkVersion to 19

Just changing the compileSdkVersion to 19 in android-project/app/build.gradle fixed it for me. It doesn't look like targetSdkVersion needs to be changed.

On 2017-11-19 01:43:09 +0000, Olli Kallioinen wrote:

Created attachment 3092
Handling system UI visibility

Recently View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY was just commented out because it required API 19. Personally I think increasing compileSdkVersion should not be a problem and the reports were just coming because compileSdkVersion is 16 in the the sample project. So a better solution is to bump that version to 19. After all google recommends building with the newest SDK anyway, even if targetting older devices. Of course the version checks need to be added for API 19 in the Java code.

I did somewhat extensive testing on this (I only have one device but I tested with emulators with API levels 15,16,19,25) and here's what I found:

Hiding the status bar and the title bar works fine just by setting the theme in the app manifest for all the API levels I tested. On API >= 19 the status bar will hide and show automatically and on levels below that it will be permanently hidden. If we remove the code controlling the bars, the user can easily disable hiding them in the manifest.

However, the navigation buttons can be properly hidden only in code and only for devices that have api level >= 19. While older devices support a mode where the navigation is hidden, the bars will pop back if the screen is touched anywhere (instead of dragging from the edge) so it's really only useful for video player apps and not games and such.

So I think the best solution is to bump the compileSdkVersion to 19 and check for api 19 and hide navigation only then. Also I think hiding navigation should be optional too. So I created a patch where the hiding is a separate method that can be easily overridden by the user.

On 2017-11-19 14:57:16 +0000, Olli Kallioinen wrote:

I was also thinking that maybe there could be something like this in the top of the java class that would
Make the error clearer to anyone trying to build with a too low compile version:

// Your compileSdkVersion (in build.gradle) needs to be at least 19.
@SuppressWarnings("unused")
private static final int REQUIRED_MINIMUM_COMPILE_SDK_VERSION_IS_19 = Build.VERSION_CODES.KITKAT;

It's just an unused field that is set to a constant that is not defined before 19. Maybe there is a better way to do something like this, but I couldn't find one with a quick search.

On 2017-12-05 15:14:49 +0000, Sylvain wrote:

This break-compilation flags sounds a good idea ! I think it should be added!