Back button handling between 51.1 and 51.3

[dmunsie]

Resolved. Turns out this bug is caused by using Distriqt's Application ANE. More specifically this line...

Application.service.display.setDisplayMode(DisplayMode.IMMERSIVE, LayoutMode.CUTOUT_SHORT_EDGES);

I will report the bug to them. ;)

Thank you for the back and forth, I apologize for taking up your time. The latest release is solid. :)

Thanks again.

Adobe AIR 51.1 SDK - Back button behavior works as expected.

Adobe AIR 51.3 SDK - Regardless where in the app, when the back button is pressed for the first time the app minimizes. After that the app behaves correctly.

enableOnBackInvokedCallback="false" in manifest does not fix it.

Anyone else?

[marchbold]

Is this just happening in an empty app? Do you add a listener for the back event handler at all? eg:

NativeApplication.nativeApplication.addEventListener( KeyboardEvent.KEY_DOWN, keyDownHandler );

function keyDownHandler( event:KeyboardEvent ):void
{
	trace( event.keyCode );
	if (event.keyCode == Keyboard.BACK)
	{
		event.preventDefault();
	}
}

You wouldn't be using any of my legacy back button helpers at all would you? https://docs.airnativeextensions.com/docs/application/general-helpers#air-android-sdk-28-back-button

[dmunsie]

Hello, I haven't created an empty app, due to I spent a couple of hours messing around and then it worked fine on the older SDK, so something had to have changed. It's the same code base I have been using for a long time. Yep, I use the keyboard listener to handle backspace and preventdefault. Worked like this for years. Just not working in the latest release. It's a minor bug, because the app just minimizes the first time and from then it works fine. So it may be overlooked by most devs and users. No, I'm not using the legacy helper you mentioned. Verified on 2 devices, tablet and phone. Thanks.

…

On Wed, Mar 11, 2026 at 7:54 PM Michael ***@***.***> wrote: Is this just happening in an empty app? Do you add a listener for the back event handler at all? eg: NativeApplication.nativeApplication.addEventListener( KeyboardEvent.KEY_DOWN, keyDownHandler ); function keyDownHandler( event:KeyboardEvent ):void { trace( event.keyCode ); if (event.keyCode == Keyboard.BACK) { event.preventDefault(); } } You wouldn't be using any of my legacy back button helpers at all would you? https://docs.airnativeextensions.com/docs/application/general-helpers#air-android-sdk-28-back-button — Reply to this email directly, view it on GitHub <#4180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK2UE4JTM2CDBXK7PZCNK3L4QIDDDAVCNFSM6AAAAACWO6CNLSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBZGA2TKMI> . You are receiving this because you authored the thread.Message ID: <airsdk/Adobe-Runtime-Support/repo-discussions/4180/comments/16090551@ github.com>

[marchbold]

Thanks for the additional info, I'll run some tests myself

[marchbold]

Hey I've just setup a super simple application that grabs the KEY_DOWN event at launch and not seeing any issues here. The first back press is handled by the event listener.

Is there any chance there's a flow issue here and you're not attaching the listener on the first run? Perhaps something else has changed in the startup flow in 51.3?

What Android SDK and build tool versions are you using?

[dmunsie]

ok.. I just updated everything on my end to reflect the notes in the release...

Platform Tools: 28.0.3 (I had to google that where to find it.)
Build Tools: 35.0.0
SDK Platform: Android-35

And the same thing happens. So the fact that it's not happening on your end is good.

"Is there any chance there's a flow issue here and you're not attaching the listener on the first run? Perhaps something else has changed in the startup flow in 51.3?"

Nothing has changed on the start up code at least. I'll keep trying a few things. In a worse case scenario it's a bug that isn't going to stop anyone from using the app. Thx.

[dmunsie]

No luck, but after doing extensive testing with an AI agent (Claude), it seems there could be an issue with this version of the SDK in regards to Stage3D which was not in the older SDK. I was able to write a simple non Stage3D test app and the back button worked fine the first time, but when utilizing my stage3D engine the back button does not work correctly the first time, but from the 2nd time on... it works fine.

51.1 works as expected. 51.3 does not.

So since no one else has reported the issue, it very well could be with my custom Stage3D code base. I'm not too concerned to be honest, as the bug is a small one that most will never notice. But for a sanity check on the SDK 51.3, it would be great if someone has a stage3D mobile app using SDK 51.3 and can verify the back button is working fine the first time it's pressed.

In my game for example, during the game you can press the back button to exit to the title screen. But with SDK 51.3, the app just minimizes instead of going to the title screen. With SDK 51.1, it exits back to the title screen. Thx!

[marchbold]

Seems an odd one to be related to Stage3D, but something could have changed in the way AIR starts up which may be affecting the flow of your app? Any chance you can set some break points and check if your listener is actually getting added on the first launch?

[dmunsie]

"Any chance you can set some break points and check if your listener is actually getting added on the first launch?"

Just to clear, I'm not re-launching the app and then it works. It's just going from a stopped state back to active.

Launch the app. Start playing the game. During the game press the back button which should take it immediately to the title screen. Instead the app gets stopped. When tapped to be the active app again, the game is paused (correct behavior) and I can continue playing. But when I now press the back button (2nd time) it exits back to the title screen correctly.

What causes me to continue to think it's not on my end is when using 51.1 to build the apk the app works as expect, but when building with 51.3 it does not. I'm not re-compiling the .swf between builds. Do you still think continued testing with my code base is relevant if it's not happening on such a close SDK revision to the current one?

Hopefully someone else running stage 3D / 51.3 will chime in with their results.

Thanks!

[marchbold]

Yeah totally understand. Not saying there isn't an issue, just trying to isolate the cause.

What I mean is that potentially there is something like the "activate" event that you are waiting for to attach your back button listener and this isn't getting fired for you on the first launch in 51.3, but is getting fired when the app comes to the foreground after being minimised?

So if you could launch your app in debug mode and set a breakpoint where you attach your back button listener to confirm if it's getting to that spot in your code on first launch.

[dmunsie]

So if you could launch your app in debug mode and set a breakpoint where you attach your back button listener to confirm if it's getting to that spot in your code on first launch.

Ok, I'll give that a try, but just to clarify what I'm looking for... what do I need to be looking for in order to confirm the listeners are being set on first launch? I'm a little confused on how to proceed. Thanks.

[marchbold]

Something like the code above where you are listening for the key down event and handling the keyboard back code.

[dmunsie]

Something like the code above where you are listening for the key down event and handling the keyboard back code.

Sorry for not understanding... the code for handling the back code is already in place and is what I've been testing.

To test further on the new SDK you suggested "launch your app in debug mode and set a breakpoint where you attach your back button listener to confirm if it's getting to that spot in your code on first launch".

How will I know if "it's getting to that spot in your code on first launch"? That's what I'm not understanding. Sorry... thx!

[marchbold]

Can you set a breakpoint in your IDE?

[dmunsie]

You made me go back a few years... lol.. I use FlashDevelop and the FlashDevelop debugger requires an older version of Java then what is installed. I'd have to switch to the newer java for building, switch to older java for debugging. ugh... lol.. I appreciate the back and forth. But it looks like I'm the only one reporting the issue, and I'm fine with the quirk as is. It's definitely not going to stop anyone from using the app. And it will only show up once per app run. Thanks!

But let's keep this open for a while incase someone else has the same issue. ;)

[marchbold]

Ha ha, oh okay, you could try using my Debug ANE and writing a native log when the listener gets added then search the adb logcat for the log?

Actually haven't used it in a while but it should still be working: https://github.com/airnativeextensions/ANE-Debug

[marchbold]

Debug.service.log( "some message", "TAG (optional)" );

[dmunsie]

"when the listener gets added"

I did this earlier... in both SDK versions... with the same results for each SDK:

(Added the keyboard listeners.... )
First thing the app does.
Right before Stage3D setup.
Right after Stage3D setup.
Right after the initial title screen is rendering.

Are you suggesting there could be some kind of delay until the listeners are actually "listening for events" after I set them up and somehow the default Android handler is trapping them instead initially? If so.. that's exactly what my AI agent suggested and that's when I started placing the SetListeners in various locations to see what would happen. And then after that session, I tried the same things on the older SDK and realized it worked fine.

If you could detail a little more what information you're seeking I could probably just set some flags/variable and display them on screen.

I don't use Starling otherwise I'd just make a simple test with it and ask you to build it on your end and simply test to see how it functions. :) Would be the quickest way to see if it's just.... me. lol..

[dmunsie]

Resolved. Turns out this bug is caused by using Distriqt's Application ANE. More specifically this line...

Application.service.display.setDisplayMode(DisplayMode.IMMERSIVE, LayoutMode.CUTOUT_SHORT_EDGES);

I will report the bug to them. ;)

Thank you for the back and forth, I apologize for taking up your time. The latest release is solid. :)

Thanks again.

[marchbold]

Ah the Application ANE display functions have all been deprecated in favour of the new Display extension. Try replacing that call with the new Display extension and hopefully that should resolve it.

You'll find some additional information on the new extension here:

https://docs.airnativeextensions.com/news/2025/12/16/edge-to-edge-displays