50.2.3.6 ACTIVATE / DEACTIVATE events issues

[marchbold]

Seems to be a result of the change made in https://github.com/airsdk/Adobe-Runtime-Support/issues/2772

Problem Description

Using 50.2.3.6 we get a DEACTIVATE event dispatched whenever a native view is added to the application and a corresponding ACTIVATE event when the view is removed. This includes things like native dialogs, camera components, video players etc.

Additionally we get a DEACTIVATE event when the notification panel is slid down or the application drawer is displayed.

Almost seems as though these events are tied to the main view's focus and not the application active state?

Steps to Reproduce

Add the native application ACTIVATE / DEACTIVATE listeners and then pull down the notification panel.

NativeApplication.nativeApplication.addEventListener( Event.ACTIVATE, activateHandler, false, 0, true );
NativeApplication.nativeApplication.addEventListener( Event.DEACTIVATE, deactivateHandler, false, 0, true );

function activateHandler( event:Event ):void
{
    trace( "activateHandler()" );
}

function deactivateHandler( event:Event ):void
{
    trace( "deactivateHandler()" );
}

We would expect no DEACTIVATE event in this scenario, however 50.2.3.6 dispatches one here.

Secondly use a simple alert dialog:

Dialog.service.create(
    new ActivityBuilder()
            .setTheme( new DialogTheme( DialogTheme.DEVICE_DEFAULT_DARK ) )
            .setStyle( DialogType.STYLE_SPINNER )
            .setCancelable( true )
            .build()
)
    .show();

This will dispatch a deactivate event, when only a view is added and the activity is still active.

Known Workarounds

50.2.3.5 does not exhibit this behaviour.

[Shaunmax]

50.2.3.5 does not exhibit this behaviour.

I can reproduce the issue starting from 50.2.3.1 to the latest build.

[marchbold]

@Shaunmax I'd suggest your issue is something else as this behaviour is definitely new.

[Shaunmax]

@Shaunmax I'd suggest your issue is something else as this behaviour is definitely new.

i checked the build in 50.2.2.6, the behaviour is that, while taking screenshot or checking notification there is no ACTIVATE / DEACTIVATE events triggered. So I would go with that as the expected behaviour.

[ajwfrost]

Hi

It seems that the change in 50.2.3.6 had wider implications than we had realised.. I'd agree with your comment in https://github.com/airsdk/Adobe-Runtime-Support/issues/2772#issuecomment-1773598602

So:

• short term, we can roll back the change
• and then we'll plan to have a basic NativeWindow implementation for mobile so that we can provide this focus event, which will then allow us to gradually expand that functionality to match how Android/iPadOS are slowly moving towards having more desktop-like capabilities..

thanks

[Shaunmax]

@Shaunmax I'd suggest your issue is something else as this behaviour is definitely new.

i checked the build in 50.2.2.6, the behaviour is that, while taking screenshot or checking notification there is no ACTIVATE / DEACTIVATE events triggered. So I would go with that as the expected behaviour.

@ajwfrost could you please confirm on this ? was anything changed after 50.2.2.6to trigger ACTIVATE / DEACTIVATE events

[ajwfrost]

@Shaunmax yes for the activate/deactivate events, we had made a change in 50.2.3.6 under bug #2772 .. although "bug" is hard to determine perhaps, it's open to interpretation whether or not these events should fire when the application is moved into the switcher view. But it may not have helped that some phones didn't send the events they were meant to so we took it a bit further to send deactivate when the AIR activity lost focus, which is what caused the issue here.

If we revert to the situation where activate/deactivate are in line with the activity lifecycle events from Android (pause/resume) then it will probably help this issue; but for the initial problem from #2772 we would need to provide an alternative event to listen out for, hence looking at using the NativeWindow activate/deactivate here for the window focus, rather than the NativeApplication activate/deactivate.

[Shaunmax]

@Shaunmax yes for the activate/deactivate events, we had made a change in 50.2.3.6 under bug #2772 .. although "bug" is hard to determine perhaps, it's open to interpretation whether or not these events should fire when the application is moved into the switcher view. But it may not have helped that some phones didn't send the events they were meant to so we took it a bit further to send deactivate when the AIR activity lost focus, which is what caused the issue here.

If we revert to the situation where activate/deactivate are in line with the activity lifecycle events from Android (pause/resume) then it will probably help this issue; but for the initial problem from #2772 we would need to provide an alternative event to listen out for, hence looking at using the NativeWindow activate/deactivate here for the window focus, rather than the NativeApplication activate/deactivate.

I understand the changes made for 50.2.3.6, but before that there is a change for firing activate/deactivate events in 50.2.3.1 which was not there in the previous version 50.2.2.6

[ajwfrost]

Hmm.. there weren't any changes relating to this between 50.2.2.6 and 50.2.3.1, although there was a fairly significant update to using the Android SDK 33 so potentially there's a behavioural change in that which is causing a difference.

Are you able to create a basic test case that we can try out to see if we're able to work out what's changed and how we may be able to get it to work the way it used to..?

thanks

[Shaunmax]

Are you able to create a basic test case that we can try out to see if we're able to work out what's changed and how we may be able to get it to work the way it used to..?

this is the change - it's triggering deactivate events in 50.2.3.1 which was not there before :

https://github.com/airsdk/Adobe-Runtime-Support/assets/16576562/254ddcaa-842a-459c-9570-3a6b29073433

[ajwfrost]

Ah okay .. that one says it's 50.2.3.5, and that would actually make sense, I just double-checked and we made the changes in both 50.2.3.5 and further in 50.2.3.6:

50.2.3.5: [github-2772] Ensuring AIR activate/deactivate events are sent on activity focus events 50.2.3.6: [github-2772] Sending activate/deactivate events based on Android window focus

So what you're seeing is the result of the handling of https://developer.android.com/reference/android/app/Activity#onTopResumedActivityChanged(boolean)

We'll revert that part too, I had wondered...

So then, with apologies to @takazawa-gg, we'll revert the two changes we made to get the deactivate events to happen in #2772, and will shortly be adding NativeWindow support where window activation/deactivation is separate to application activation/deactivation (at least, we'll check this, it may be a 'focus' event may be more appropriate but we should aim for consistency with the desktop multi-window support..)

thanks

[Shaunmax]

@marchbold I just found out that this issue is happening with the update of 50.2.3.5 & not with it's initial release. All my previous builds were pointing to 50.2.3.5 even after they were in separate folders. Could you please clarify what exactly happens when we use update option in AIR SDK Manager for each releases ?

@ajwfrost I was wrong earlier, this issue started from the update of 50.2.3.5 not before that!

[takazawa-gg]

For our part, we do not feel bad about the separation of events into "focus" and "activate, deactivate" events. It also seems to be easy to understand since it works the same way as Unity.

We have already updated 66 apps with AIR SDK 50.2.3.5. So far our apps have not reported any issues like this Issue, so we will continue to use 50.2.3.5 as is for this update. If the next time you update it you need to update it to accommodate the Focus event, we are fine with that. The next scheduled update will be when the AppStore or GooglePlay requirements are updated.

[ajwfrost]

Thanks @takazawa-gg

@Shaunmax the 'update' in SDK Manager just updates the least-significant build number i.e. 50.2.3.x .. the idea is that these updates are all just bug fixes so it should be very low risk to update these ones. Obviously this time we got that wrong, sorry! Perhaps to ensure it works again (i.e. the 50.2.3.x version does actually work with these activate/deactivate events only happening on Activity lifestyle changes) we should push out 50.2.3.7....

thanks

[marchbold]

A seemingly innocent change :) I think the main point to note here is that Android by design, doesn't want applications to "deactivate" in these situations, eg when the notification bar is opened. So this definitely should be a different event.

I think #2880 is the more significant side effect, particularly for extensions, so please make sure that one is rolled back as well.

[marchbold]

@Shaunmax Just to elaborate on @ajwfrost, if you had installed 50.2.3.5 and then hit "update" then the AIRSDKManager would have updated your installation to the latest 50.2.3.x release available. It doesn't update minor versions, but updates to the latest build version (last number). So you likely were actually running 50.2.3.6 if you had pressed update on a 50.2.3.x installation. It should show this in the UI though?

By default the AIR SDK Manager creates folders named AIRSDK_50.2.3 with no build version on the folder name, to clarify the installation isn't a specific build.

[Shaunmax]

if you had installed 50.2.3.5 and then hit "update" then the AIRSDKManager would have updated your installation to the latest 50.2.3.x release available. It doesn't update minor versions, but updates to the latest build version (last number).

isn't that little confusing? I mean take my case itself, I assumed that i was changing downgrading, but in the actual case all 50.2.3.x versions were pointing to the latest build.

[marchbold]

@Shaunmax What would you expect happen when you click "Update" on an AIR SDK? Surely you'd expect it to be updated to the latest build? If you want to keep a specific version like you have there, just don't update it? Generally "build" version updates are only supposed to be bug fixes so shouldn't change functionality. (This issue being an exception).

Note: IntelliJ has a bug where it doesn't update the version listed in that image unless you remove and add the sdk again.