Mobile - Exiting and Reopening App Cuts Off Portion of Screen

For reference I am using Haxe 4rc3 and Lime 7.5.0. I am getting this error on my test app, the lime samples, and the openfl samples at version 8.9.1. By opening the app, hitting the ‘Overview’ button, and going back to the same app, it will create a black bar at the bottom of the screen. Here’s an example of that in pictures:




I am using Android version 8.0.0. What is interesting to note is that setting the option <window resizeable="false"/> doesn’t stop the app from resizing, as I still receive the resizing event from Lime.

I’m getting this too. In my case it happens on start but if I get the top menu down with a finger flick when it goes back up again the black bar goes away. But up until I do that it’s just there chilling. I don’t know why.

Is this a regression? We used a newer version of SDL in recent releases but have seen problems with it so now we are testing an even newer version in the Lime dev repository

Hi, thanks for the response. I saw the commit in Github and built from source. Unfortunately now it crashes before completing preloading, and console is empty :confused:
If there’s something I can do to help, let me know!

Were you using a dev version of OpenFL? I resolved a regression yesterday with SWF content that could have been affecting your build. If you did use a dev version of OpenFL, please pull again and run openfl rebuild tools before testing.

If there is still a problem I may have to test on Android again tomorrow when I’m back at my desk

Nope, I’m using openfl 8.9.1, although the samples are 8.7.0. I’m actually trying to build a lime app using the opengl context. I pulled and tried out the current version on Github, and it works for neko targets, but crashes on Android without an error message.
However, the NyanCat demo crashes on neko with the error message

$ lime test neko
Called from ? line 1
Called from ApplicationMain.hx line 25
Called from ApplicationMain.hx line 130
Called from lime/app/Application.hx line 150
Called from lime/_internal/backend/native/NativeApplication.hx line 146
Called from a C function
Called from lime/_internal/backend/native/NativeApplication.hx line 175
Called from lime/_internal/macros/EventMacro.hx line 91
Called from lime/system/ThreadPool.hx line 203
Called from lime/_internal/macros/EventMacro.hx line 91
Called from lime/_internal/backend/native/NativeHTTPRequest.hx line 469
Called from lime/app/Promise.hx line 149
Called from lime/app/Promise.hx line 149
Called from lime/app/Promise.hx line 149
Called from openfl/net/URLLoader.hx line 411
Called from openfl/events/EventDispatcher.hx line 246
Called from openfl/events/EventDispatcher.hx line 402
Called from openfl/_internal/formats/swf/SWFLiteLibrary.hx line 210
Called from lime/app/Promise.hx line 149
Called from lime/app/Promise.hx line 149
Called from lime/utils/Preloader.hx line 290
Called from lime/utils/Log.hx line 34
Uncaught exception - [lime.utils.Preloader] ERROR: [IOErrorEvent type=“ioError” bubbles=true cancelable=false text=“Cannot load file: lib/lib/library/library.bin” errorID=0]

Yesterday I resolved a crash error on the Android target in Lime… but I forgot to test exiting and reopening :sweat: but everything I tested was working after the fix

Awesome, thanks for the fix. The app works again, but I’m still getting the issue. I’m on Android 8, which seems to be a problem for SDL.

I am testing NyanCat now on my Nexus 5 and it looks fine, but I know that it’s running an older version of Android. My family just moved and my newer Android device is in a box but I wonder if SDL has code to hide/show the status bar that is competing with our older code that was designed to do the same:

I wonder if removing our code here would help, or if this actually is the right code but we need to run it again after returning to the application

After testing it out on my phone, it seems that removing updateSystemUI() fixes the issue of the black bar, but going back into the application is still jarring: the window seems to be resized twice, to a version with the black bar, then it is removed almost immediately after, which also makes pausing/resuming very slow.

Here’s the logcat output for SDL from my phone. Sometime after onResume() is called the window is resized to 720x1232, then nativeResume() seems to be called to resize it back to the correct 720x1280.

2019-07-19 11:29:51.949 30311-30311/? V/SDL: onStart()
2019-07-19 11:29:51.950 30311-30311/? V/SDL: onResume()
2019-07-19 11:29:52.015 30311-30311/? D/SurfaceView: BG show() Surface(name=Background for - SurfaceView - io.deemo.app/[email protected]@0) org.libsdl.app.SDLSurface{9996799 VFE… .F…ID 0,0-720,1232}
2019-07-19 11:29:52.031 30311-30311/? D/SurfaceView: surfaceCreated 1 #8 org.libsdl.app.SDLSurface{9996799 VFE… .F…ID 0,0-720,1232}
2019-07-19 11:29:52.031 30311-30311/? V/SDL: surfaceCreated()
2019-07-19 11:29:52.033 30311-30311/? D/SurfaceView: surfaceChanged (720,1232) 1 #8 org.libsdl.app.SDLSurface{9996799 VFE… .F…ID 0,0-720,1232}
2019-07-19 11:29:52.033 30311-30311/? V/SDL: surfaceChanged()
2019-07-19 11:29:52.033 30311-30311/? V/SDL: pixel format RGB_565
2019-07-19 11:29:52.034 30311-30311/? V/SDL: Window size: 720x1232
2019-07-19 11:29:52.034 30311-30311/? V/SDL: Device size: 720x1280
2019-07-19 11:29:52.039 3161-7704/? I/SensorService: createSensorEventConnection package name org.libsdl.app.SDLSurface
2019-07-19 11:29:52.044 30311-30781/? V/SDL: Running main function hxcpp_main from library libApplicationMain.so
2019-07-19 11:29:52.044 30311-30781/? V/SDL: nativeRunMain()
2019-07-19 11:29:52.069 30311-30781/? D/openal: AL lib: alc_initconfig: Supported backends: opensl, sdl2, null, wave
2019-07-19 11:29:52.384 30311-30781/? V/SDL: setOrientation() orientation=-1 width=720 height=1280 resizable=true hint=
2019-07-19 11:29:52.390 30311-30311/? D/SurfaceView: BG hide() Surface(name=Background for - SurfaceView - io.deemo.app/[email protected]@1) false true org.libsdl.app.SDLSurface{9996799 VFE… .F… 0,0-720,1232}
2019-07-19 11:29:52.391 30311-30311/? D/SurfaceView: surfaceDestroyed 1 #6 org.libsdl.app.SDLSurface{9996799 VFE… .F… 0,0-720,1232}
2019-07-19 11:29:52.391 30311-30311/? V/SDL: surfaceDestroyed()
2019-07-19 11:29:52.392 30311-30311/? V/SDL: nativePause()
2019-07-19 11:29:52.396 30311-30311/? D/SurfaceView: surfaceCreated 1 #6 org.libsdl.app.SDLSurface{9996799 VFE… .F… 0,0-720,1232}
2019-07-19 11:29:52.396 30311-30311/? V/SDL: surfaceCreated()
2019-07-19 11:29:52.400 30311-30311/? D/SurfaceView: surfaceChanged (720,1232) 1 #6 org.libsdl.app.SDLSurface{9996799 VFE… .F… 0,0-720,1232}
2019-07-19 11:29:52.401 30311-30311/? V/SDL: surfaceChanged()
2019-07-19 11:29:52.401 30311-30311/? V/SDL: pixel format RGBA_8888
2019-07-19 11:29:52.402 30311-30311/? V/SDL: Window size: 720x1232
2019-07-19 11:29:52.402 30311-30311/? V/SDL: Device size: 720x1280
2019-07-19 11:29:52.906 30311-30311/? V/SDL: nativeResume()
2019-07-19 11:29:52.908 3161-11397/? I/SensorService: createSensorEventConnection package name org.libsdl.app.SDLSurface
2019-07-19 11:29:52.915 30311-30311/? D/SurfaceView: BG destroy() Surface(name=Background for - SurfaceView - io.deemo.app/[email protected]@0) org.libsdl.app.SDLSurface{9996799 VFE… .F… 0,0-720,1232}
2019-07-19 11:29:52.926 30311-30311/? V/SDL: onWindowFocusChanged(): true
2019-07-19 11:29:52.926 30311-30311/? V/SDL: nativeFocusChanged()
2019-07-19 11:29:52.972 30311-30311/? D/SurfaceView: BG hide() Surface(name=Background for - SurfaceView - io.deemo.app/[email protected]@1) false true org.libsdl.app.SDLSurface{9996799 VFE… .F…ID 0,0-720,1280}
2019-07-19 11:29:52.981 30311-30311/? D/SurfaceView: surfaceChanged (720,1280) 1 #5 org.libsdl.app.SDLSurface{9996799 VFE… .F…ID 0,0-720,1280}
2019-07-19 11:29:52.981 30311-30311/? V/SDL: surfaceChanged()
2019-07-19 11:29:52.981 30311-30311/? V/SDL: pixel format RGBA_8888
2019-07-19 11:29:52.985 30311-30311/? V/SDL: Window size: 720x1280
2019-07-19 11:29:52.985 30311-30311/? V/SDL: Device size: 720x1280

Again, the window is being resized twice, so it’s still pretty jarring. Is the SDLActivity class written for us? The issue seems to be somewhere in there.

We have minor edits to SDLActivity, but largely that’s written and supported by the SDL contributors