Black screen when returning from lock screen on Samsung S8

[MapYourShow]

Problem Description

AIR SDK: AIR 25 (Also tested on AIR 26)
Starling: 2.1
Environment: AIR, Flash Builder 4.7, Only occurs on Samsung S8 and S8+ running Android

This issue is reproducible by all co-workers with an S8 or S8+. Other users have seen this issue as well, based on feedback from the bug I put for Adobe. All users with an S8 or S8+ that use a lock screen of some kind are effected. This issue will not occur on devices with no lock screen security.

Starling Forum Thread: https://forum.starling-framework.org/topic/samsung-s8-black-screen-when-unlocking-phone
Adobe Tracker: https://tracker.adobe.com/#/view/AIR-4198366

Steps to Reproduce

I have created a small and lightweight app in Adobe AIR 26 that uses Starling, simply to test this issue.

When this app is run on a Samsung S8 or S8+, simply lock the screen (make sure to have some form of lock screen security enabled. Pattern or Retina is what most people I have spoken to are using.), once the screen turn to black, unlock the phone and the screen on the S8 will be a black screen. To resolve the issue simply put the app in back ground and reopen it, this will display the app once again.

This is due to the ACTIVATE event being dispatched twice when the phone is unlocked.

I am going to attach this small project to this issue, for testing purposes.

MYSMobileApp_Starling2.zip

[Edit by Daniel Sperl, 2018-06-11]
Here is a better sample app, all in a single startup class: MinimalMobileApp.as
[/Edit]

I have also been able to reproduce this issue on a large number of Starling apps on the Google Play Store.

Known Workarounds

I have not been able to find a viable workaround for this issue.

[MapYourShow]

Just putting this here, I cannot seem to add labels to this issue.

[PrimaryFeather]

Sorry about the labels! I added them manually for now; I'm currently on a vacation, I will try to re-configure this when I'm back home. Thanks a lot for creating the issue!!

[PrimaryFeather]

Just a quick heads-up: somebody from Adobe just posted a reply on Adobe's tracker.

[MapYourShow]

I just responded to them, hopefully this is the first step in getting this issue resolved.

[PrimaryFeather]

I just got a message from Adobe that they are currently looking into it again! However, I noticed that in your attached sample application, you didn't call "starling.start/stop" in the Event.(DE)ACTIVATE handlers. This is actually the reason why the screen stays black — i.e. this will happen on all devices, regardless of a double ACTIVATE dispatch.

That's because when starling.skipUnchangedFrames is activated (as it is in your sample), Starling won't automatically redraw when the app is activated, and the screen stays black.

Could you fix that in your sample, as shown below, and then test on an S8, if the ACTIVATE event is dispatched twice? Thanks a lot in advance!

private function stageDeactivateHandler(e:Event):void
{
	_starling.stop(true);
	trace("this is the deactivate handler");
}
private function stageActivateHandler(e:Event):void
{
	_starling.start();
	trace("This is the activate function");
}

[MapYourShow]

After adding in those start and stop methods, the S8 still gets a black screen and a double activate/deactivate each time it is locked. Should I re-upload this sample project?

[PrimaryFeather]

Thanks for looking into it so quickly!
Quick question: did you use AIR 27 for your tests?

[MapYourShow]

We are indeed using AIR 27 for our test. At least we are now, I think the sample project I uploaded initially was using 26, but I have since upgrading the project to 27.

[PrimaryFeather]

Okay, thanks!
Hm ... I told Adobe to make those changes, too, but the event is fired just once for them.

This only happens when you lock the screen, so that, when you hit the power button on device, you need to enter your pin code before going back to the app, right? It's not enough to simply switch tasks.

[MapYourShow]

Correct. We have to lock the device, and it seems to happen only if you have a lock screen of some kind. The simply swipe to unlock does not cause the issue, but if you use the pin lock, pattern lock or the facial/retina lock, then it will happen. That's how we have found it to happen at least.

[PrimaryFeather]

Okay, I'll ask Adobe if that's exactly what they tried! Will be back then. :-)

[PrimaryFeather]

Unfortunately, Adobe still can't reproduce it, I'm afraid. They write:

I have tried the same process you described in Samsung S8. I open the application, put device to sleep, then unlock the device. (The device has a pin lock.) For this case the issue is not reproducible.

However, they found one similar scenario:

I tried one more scenario. After putting the device to sleep, I clicked power button twice, which opens the camera and then the device goes to sleep. Now unlocking the device by putting in the pin sometimes results in the black screen. This is the only scenario in which I am able to reproduce the issue.

I haven't found out yet, though, if this also means that they got the "ACTIVATE" event twice.

One other thing, though: is the real problem here really that you get the "ACTIVATE" event twice? You could always ignore the second event with a flag, after all. Does this also mean that the context is lost twice? Maybe you can explain the implications a little more. Thanks in advance! 😄

[MapYourShow]

In my testing, we have been seeing double ACTIVATE and DEACTIVATE events being called. It happens every single time we do it on the S8+ in the demo app, on our released apps and on the few apps we tested from the Starling showcase. It's so weird to me that they are having this much of an issue. I will check with the QA guy here and see if he has to press the lock button twice, but this is not something I recall him doing in order to reproduce the issue. I will try to sit down and work with him today to see if I can get any more relevant info. Thanks!

[PrimaryFeather]

Yeah, it is weird, I agree. :-/

Is anyone else following this thread who has an S8 he/she could test this with? Any help would be appreciated! 😄

[MapYourShow]

I had the QA guy here try again, but we are still seeing the same results. It happens every time the screen locks or goes to sleep. With or without a pin lock, or any lock for that matter. I cannot think of anyway that they would not be seeing this issue.

[PrimaryFeather]

And that's on multiple devices, right? You said you could reproduce it on an S8 and an S8 Plus. I don't suppose there are any custom launchers (or whatever) installed, right?

[MapYourShow]

We have only been able to test on an S8+, and this does not happen on the S6 we have. He has the stock launcher and Android version that come with the phone, and his phone is not rooted. It's the same as it was when he took it out of the box.

[PrimaryFeather]

Okay. Yeah, I also tried it with those Android devices I have, and the error didn't occur there, either. Really weird.

I don't know if they used an S8 on an S8+, though. Perhaps it just happens on the latter? Doesn't seem likely, but who knows. I'll ping them again.

[MapYourShow]

I am trying to find someone here that has an S8 that I can use to test on. I will update you if I can find one.

[Xgamefactory]

this issue still remain with latest adobe air sdk. Looks like all adobes experienced engineers quit the job )
Adobe should make open source the air sdk, there are still experienced flash fan developers who can really make adobe air rise again, otherwise it will die.

[marchbold]

We've run into a few reasons a black screen can occur on returning:

• not using singleTop as the android launch mode (not sure why people are changing this but it seems to lead to this issue). Just make sure you don't have the launchMode tag in your application node.

• on some devices we have found air + starling seem to resume but the surfaceview used to render isn't updating. We've gotten around this with a small helper in an ANE Application.service.blackScreenHelper();. This basically forces the AIR surface view to update again.

Not sure if either of those help out.

[Xgamefactory]

we have added singleTop tag dues to some workarounds on other air issues.
see https://forums.adobe.com/thread/975842

[urthling]

@GeneralVimes ah, looks like if you link from the release notes, you'll get to 620

Quick note though, for iOS you may need to update ADT from this post: #1169

So, super positive results on both so far! Both my test devices appear to be coming back from sleep without issue. At this stage I would certainly have seen this issue crop up, so well done yet again Harman team!!

[ajwfrost]

Thanks @urthling
Yes, sorry @GeneralVimes I should have linked to it, as we left the .620 build as a 'beta' because we're about to do another one (with the advent of Xcode 13, a few minor changes only...)
https://airsdk.harman.com/download/33.1.1.620
thanks

[nyuntaka]

I tried AIR SDK 33.1.1.620 on A20. The issue still occurs.
thanks

[urthling]

Ah, I totally forgot about a utility function I wrote that seemed to resolve this in the past. But after a recent build it made no difference, which is when I started using the district's blackScreenHelper() from their Application ANE..

After removing my utility function, sure enough the black screen is back.

Ok, so here is the utility method I wrote:

public function exitHibernateMode(event:ApplicationEvent):void
{
	.........
				
	if (providerModel.deviceModel == 'Android Linux')
		preventBlackScreenOnAndroid(10);

	.........

private function preventBlackScreenOnAndroid(delay:uint):void
{
	var bogusButton :Button	 = providerModel.returnButton('', 'color-back-0x000000', null, null, 416, 1, 0, 1, false, 0);
	mainContent.addChild(bogusButton);
				
	var closeOut 	:Object = {};
		closeOut.timer 		= 0;
		closeOut.action 	= function():void
		{
			clearTimeout(closeOut.timer);
						
			mainContent.removeChild(bogusButton);
		}
	closeOut.timer = setTimeout(closeOut.action, delay);
}

I call the above method twice -- once after just 10ms and again after 250 ms -- if the first fails - the second generally works. So far so good, I haven't seen the black screen today with this work around in place.

The button I'm pulling from my providerModel is the full width of the display (scaled) and 1 pixel in height and opacity of 0 -- anything smaller I remember wasn't effective. Anyway, as you can see, I'm simply adding it and removing it.

I'm happy that 620 at least restores this functionality -- but it would be preferable not to have to use this workaround of course..

[ajwfrost]

Okay thanks .. @urthling can I check whether your button is using Stage3D or whether it's just on the display list?
Plus -> do you have the flag set to 'true' in your app descriptor?

At this point, I'm wondering whether it's possible to get both the source code and a compiled binary package (apk-debug) so that we can try to make sure we're reproducing the same thing!

thanks

[urthling]

@ajwfrost yes, I'm using Feathers/Starling, so Stage3D and in my app descriptor renderMode = direct

I'm not really comfortable sharing the source, besides the App is rather large with dozens of libraries and ANEs.. but I'm more than happy of course to send you an apk-debug. Does that work?

Also, for the first time, I'm seeing the black screen now on my Samsung even with my workaround in place.. Perhaps the length of time it was asleep made the difference? However, After clicking the App Switcher button, and then reselecting my App, the black screen did disappear and my App resumed normal function.

[ajwfrost]

Thanks @urthling - sorry, I wasn't implying for you to send us the whole application, but I was wondering whether it's possible to craft a simple/empty SWF that shows the same problem....

For your final comment: so are you seeing that with the 33.1.1.620 plus your workaround, after it's been asleep a while? Do you have any screensaver/active wallpaper?

I just noticed my question earlier got formatted out, I was hoping to check whether you have <containsVideo> set to true in the app descriptor...

thanks

[urthling]

@ajwfrost Gotcha, yes, I can put together a sample App for sure -- not sure if I'll be able to get it to you today but if not then over the weekend shouldn't be an issue.

Yes, I also have <containsVideo>true</containsVideo> in the app descriptor

Yes, 33.1.1.620 plus the workaround, after several hours asleep, I saw the blackscreen this am. Touching the screen, it remained black.. using the app switcher and reselecting my app it showed as normal (didn't relaunch - just appeared)

Simple pattern lock and default theme with a background photo

[urthling]

@ajwfrost This demonstrates the issue and workaround -- if you comment out the call to; preventBlackScreenOnAndroid() once you see the trace statement: In Context - Hibernate coming out of sleep you'll see the Blackscreen

[GeneralVimes]

Finally got my hands on AIR 633, compiled a game with it, can confirm that the black scree issue is there, like before, on Samsung A30s

[urthling]

@GeneralVimes did you try the workaround in #6 (comment) ? this should reduce the occurrences of the black screen until Harman releases a real fix..

[nyuntaka]

I'm sorry I don't know how to use it. Can I ask how to use it? Where is exitHibernateMode called?
Thank you.

[urthling]

@nyuntaka You can listen for a native event like this:

NativeApplication.nativeApplication.addEventListener(Event.ACTIVATE , exitHibernateMode);

[nyuntaka]

Thank you very much. I tried to check the issue again before trying it.
However, for some reason, the issue did not occur.
The OS of Galaxy A20 was updated by au. It may have been fixed.
https://www.au.com/information/notice_mobile/update/update-202109-scv46/

[ajwfrost]

It would be interesting to see whether devices no longer exhibit the problem when they're updated to Android 11 like that. We are convinced it's to do with the layering of surfaces by the OS but it has been strange how it's only specific devices (and always Samsung?!) that are affected. And how some cases can't be reproduced here on the same hardware as folk are reporting the problems on (so perhaps the OS versions are different and we should look at that too....)

I'd be happier of course if we knew how to avoid it! The problem going away by itself is a little concerning because I suspect it would be likely to then come back by itself in a future OS update!

thanks

[urthling]

Ah, that is interesting! There isn't an official update for my old Note 8 but if newer models and future OSs won't experience this, then hurah!

[itlancer]

May be latest AIR 50.2.4.1 with patch #1003 (comment) fix this issue for Android.