Black screen after 5 minutes of inactivity

[raresn]

Black screen when swiching back to Android App. Tested on Android 13 Baseversion S916BXXU3AWHH Phone model: Samsung S23+

black_screen.txt black_screen_with_the_app_in_forground.txt Steps to replicate:

• start the app
• put it in background
• lock phone
• wait 5 minutes (this is consistent, managed to replicate even with 4, but with 5 always)
• unlock phone
• switch to app
• app screen is black

logcat data 1: black_screen.txt Started logging after locking the screen Unlocked after 5 minutes, switch to app. -> black screen

logcat data 2: black_screen_when_app_in_forground.txt With the app in forground, locked screen, then unlocked -> app is ok.

Video: https://youtu.be/E63lrrU1z_U

@ajwfrost sry to add to the worklog, but here is another problem we are having. What other info can i provide? The app is live and can be downloaded from: https://play.google.com/store/apps/details?id=air.ro.fxstudio.agenda

[raresn]

@ajwfrost replicable without extensions in the xml and an empty swf.

[itlancer]

May be related issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/2017 https://github.com/airsdk/Adobe-Runtime-Support/issues/1194 https://github.com/airsdk/Adobe-Runtime-Support/issues/1003 https://github.com/airsdk/Adobe-Runtime-Support/issues/6

[raresn]

With air 50_2_2_2 we get the same behaviour. and With air 50_2_3_6 we get the same behaviour.

[raresn]

Demo hello world app. Inside the folder OUT you have

• compile
• production

@ajwfrost @marchbold Inside the compile, you have the xml swf and a precompiled apk. It should be as straightforward as possible to replicate. Edit APK_ANDROID.BAT

• change D:\AdobeAIRSDK\bin\adt.bat to your path to the sdk
• change -keystore androidMarket.p12 -storepass xxx with your p12 and password
• compile

OR/AND

1) Run the app 2) - important! - put it in background 3) Lock the phone 4) - important! - wait 5 minutes - doesn't happen if the time is shorter. 5) Unlock phone 6) Switch to the app Teeeeeesst.zip

[ajwfrost]

Hi - we've reproduced this, thanks for all the info and analysis. From the first look at our logs, it seems that everything should have been working - we can see the app coming back into focus and the creation of the new graphics surface, the rendering etc. Will have to check whether there's some sort of race condition or invalid event ordering...

thanks

[raresn]

@ajwfrost super happy to hear this! Can't wait to have it fixes so we can cut down on the phonecalls from our clients :))

[raresn]

No pressure, but do you think you can give me a time horizon where this could possible be fixed? (need to know because this is affecting all our Android users)

[ajwfrost]

One of the team is investigating, we have a plan for trying to narrow down a likely cause (which hopefully then leads directly to the workaround) - but it's one of those fairly low-level issues which means we have to wade through a large amount of trace logs to work out what may be happening. I would hope we find and fix it within the next two weeks..

thanks

[ajwfrost]

Okay so apparently, after the process has been in the background for a while - on certain devices (Samsungs?!) - we no longer get the callbacks for display state changes. Which means that when the screen is turned back on, we don't get to know about it, and the whole thing stops working (it's also running at a throttled background rate..)

So a change to check the actual display state during the "onRestart" activity lifecycle change, and this should then be fixed...

thanks

[raresn]

@ajwfrost super! Sounds like an easy fix :) any plan to roll out a hot fix for this?

[ajwfrost]

@raresn given where the fix is located, that's actually fairly trivial to do -> so if you unzip the below, this should go into the AIR SDK (50.2.3.6) under "lib/android/lib/"

runtimeClasses.jar.zip

@itlancer given this was specifically to do with the app being in the background for a while and then the display state changing, I'm not sure the fix will impact those other issues, but we are looking into them..

thanks

[chrslgr]

is it possible that this fixes the iOS-issue too?

[Devin-Licastro]

ooh this is great, I had some Samsung users reporting this and this explains it. Lovely.

[itlancer]

@ajwfrost Just for information. This patch didn't help with issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/1194 https://github.com/airsdk/Adobe-Runtime-Support/issues/1003

Other related issues not tested.

[raresn]

@ajwfrost good news - problem is gone with the hot fix! You have no idea how much time this saved us for customer support :) Thank you.

[NikosLaskaridis]

@ajwfrost will this work with Air SDK 50.2.3.5? I'm using this version since I compile using Animate.

[raresn]

@ajwfrost do we still have to add this in the latest 50.2.3.6?

[ajwfrost]

@raresn for 50.2.3.6 yes the updated runtimeClasses.jar would be needed, but this fix has gone into 50.2.3.7 which is now available.

@NikosLaskaridis yes you could apply this patch over 50.2.3.5 I believe, you'd get a few other bits of functionality from 50.2.3.6 but I don't believe there's any changes to the JNI interface so it should still work.

@chrslgr sorry, this one is just Android-specific, it looks like there are some lifecycle handling changes on iOS too so we'll look into that one.

This bug is specifically about having a black screen when coming back to an app after 5 minutes of inactivity in a lock screen, and seems pretty specific to Samsung as well (couldn't reproduce on a Pixel) - caused by the app not receiving the event about the screen unlocking. So I'll close this one, as there are other issues mentioned above that cover the black screen problems in different scenarios..

thanks