StartApp - Bad actor on resume

I just spent a few hours integrating in startapp and found a curious behavior.  I have it set to only display an interstitial ad on a particular transition which is working fine.  However, I noticed ads are displayed whenever my app resumes from a suspended state.  startapp.show() was not called and I see no callback about an ad being shown occurring to the listener I registered.   The startapp API is rather simple and I don’t see any way to prevent this behavior. Very disturbing.

  Docs on it: https://docs.coronalabs.com/plugin/startapp/

Has anybody else seen this behavior?  Do other monitization plugins also behave this way?

Env: Corona 2017.3184

-Mijeo Studios

Do you have code in your system resume handler? Maybe share that code with us?

Rob

Hi Rob,

I do have some simple resume code which does this:

   native.setProperty( “androidSystemUiVisibility”, “immersiveSticky”)

I did some more testing today and noticed that the strange behavior is not consistent. It seems to  be triggered by particular ads and whether or not I click on the ad.  Kinda implies the bad behavior is resulting from the ad itself.  If these ad’s are implemented as plugin like code then, they code easily add in hooks for resume behavior.  

I know StartApp is rather new to Corona, but it’s still difficult to imagine someone has not seen this before?  Anybody?

Thank you,

Jim

Normally on Android, when you click on things that open other full-screen windows, like an interstitial ad, your app will suspend and then resume when the ad closes.  StartApp makes their own plugin, so if it’s misbehaving you might want to reach out to them.

Rob

Did you turn off return ads. It is set to true by default:

startapp.init( listener, params )

The params table includes parameters for the StartApp initialization.

appID (required)

String. The app ID for your app, gathered from the StartApp portal.

enableReturnAds (optional)

Boolean. Set this value to false to disable return ads. Default is true.

Hello Agramonte,

Looks like I glossed over that one, thanks for the catch.  I do remember wondering about it at the time, but I didn’t make the “return” = ad on resume app connection, and just figured the default setting would be good and moved on.  I can’t imagine why anyone would want this on. 

For clarity, it didn’t always behave as configured via this setting.  Some amount of time needed to transpire before a resume app would trigger an ad (maybe 20+ seconds).  When it did do a resume ad, I found no notification call back occurring about the shown ad.  I’ll report this to SmartApp.

Thank you,

-Jim

Jim:

My thought exactly when I saw it. I think the default should be false since other than cause people to uninstall the app I can’t imagine any other use.

Do you have code in your system resume handler? Maybe share that code with us?

Rob

Hi Rob,

I do have some simple resume code which does this:

   native.setProperty( “androidSystemUiVisibility”, “immersiveSticky”)

I did some more testing today and noticed that the strange behavior is not consistent. It seems to  be triggered by particular ads and whether or not I click on the ad.  Kinda implies the bad behavior is resulting from the ad itself.  If these ad’s are implemented as plugin like code then, they code easily add in hooks for resume behavior.  

I know StartApp is rather new to Corona, but it’s still difficult to imagine someone has not seen this before?  Anybody?

Thank you,

Jim

Normally on Android, when you click on things that open other full-screen windows, like an interstitial ad, your app will suspend and then resume when the ad closes.  StartApp makes their own plugin, so if it’s misbehaving you might want to reach out to them.

Rob

Did you turn off return ads. It is set to true by default:

startapp.init( listener, params )

The params table includes parameters for the StartApp initialization.

appID (required)

String. The app ID for your app, gathered from the StartApp portal.

enableReturnAds (optional)

Boolean. Set this value to false to disable return ads. Default is true.

Hello Agramonte,

Looks like I glossed over that one, thanks for the catch.  I do remember wondering about it at the time, but I didn’t make the “return” = ad on resume app connection, and just figured the default setting would be good and moved on.  I can’t imagine why anyone would want this on. 

For clarity, it didn’t always behave as configured via this setting.  Some amount of time needed to transpire before a resume app would trigger an ad (maybe 20+ seconds).  When it did do a resume ad, I found no notification call back occurring about the shown ad.  I’ll report this to SmartApp.

Thank you,

-Jim

Jim:

My thought exactly when I saw it. I think the default should be false since other than cause people to uninstall the app I can’t imagine any other use.