AppLovin - getting "validationSucceeded" phase without showing a video

We noticed a strange bug in the AppLovin plugin:

The isLoaded() function return true, so we try to show a video. 

One second later, the user gets the following 3 callbacks:

  1. phase=validationSucceeded, event.isError=nil, event.response=nil

  2. phase=playbackBegan, event.isError=nil, event.response=nil

  3. phase=displayed, event.isError=nil, event.response=nil

Sometimes 3 is received before 2, but the first event is always the “validationSucceeded” event, and these events are always 1 second after show(). 

Obviously, a video has not been shown to the user. 

Why is this happening? the isLoaded() should return false if it can’t show a video, and if it fails to show the video, the “validationSucceeded” event should not be sent (we use this callback to reward our users). 

Maybe this has something to do with the fact that the user is from east Asia? (a fill issue causing the plugin to go crazy?)

The user has an Android device (os version 5.0.2, model Mi 4i)

Thanks

Hey Stanga.

This is similar to the Revmob question you posted. 

Again, the plugin relies on Applovin events to set the correct event phases. So if these phases are seemingly in the wrong order, it isn’t the plugin that is doing that, it’s the Applovin SDK.

I can tell you that getting the displayed event before the playbackBegan event is normal. The displayed event can also mean that the video frame is displayed. So naturally that can occur before the actual playback of the video begins (due to latency).

The reason you are seeing the events bunched up, is due to the corona thread being blocked whilst the video is playing. That is why the events will seemingly come in a bunch. This is common with a lot of plugins.

Hi Danny, 

The problem is not the order of the events, or that they are bunched up. 

The problem is that after calling show(), the user is not shown a video, yet the isLoaded() function returned true prior to the show() call. 

What is worse is there is a “validationSucceeded” event a second after the show() call, even though the user has not seen a video, therefore should not actually be rewarded. 

There is a good chance this is an issue in AppLovin’s end, but I would really appreciate it if you could investigate this and possibly pass it to AppLovin.

Thanks!

Sorry for the late response on this.

We’re in the process of updating to the latest version of the Applovin SDK.

The issue does indeed look like it’s on their end, so we’ll see if any progress is made on this issue after we finish the update to the plugin.

I’ll let you know when the update is released.

Thanks

Hey Stanga.

This is similar to the Revmob question you posted. 

Again, the plugin relies on Applovin events to set the correct event phases. So if these phases are seemingly in the wrong order, it isn’t the plugin that is doing that, it’s the Applovin SDK.

I can tell you that getting the displayed event before the playbackBegan event is normal. The displayed event can also mean that the video frame is displayed. So naturally that can occur before the actual playback of the video begins (due to latency).

The reason you are seeing the events bunched up, is due to the corona thread being blocked whilst the video is playing. That is why the events will seemingly come in a bunch. This is common with a lot of plugins.

Hi Danny, 

The problem is not the order of the events, or that they are bunched up. 

The problem is that after calling show(), the user is not shown a video, yet the isLoaded() function returned true prior to the show() call. 

What is worse is there is a “validationSucceeded” event a second after the show() call, even though the user has not seen a video, therefore should not actually be rewarded. 

There is a good chance this is an issue in AppLovin’s end, but I would really appreciate it if you could investigate this and possibly pass it to AppLovin.

Thanks!

Sorry for the late response on this.

We’re in the process of updating to the latest version of the Applovin SDK.

The issue does indeed look like it’s on their end, so we’ll see if any progress is made on this issue after we finish the update to the plugin.

I’ll let you know when the update is released.

Thanks