CoronaActivity EXIT & SUSPEND inconsistent between devices

Solar2D Native builds
#1

I’m running Enterprise with Android, and I’m seeing some inconsistencies between 2 devices: 

  • HTC phone running Android 4.4.2
  • Nexus 7 tablet running Android 4.2.2

My project runs activities that are supposed to only suspend the CoronaActivity for a little bit (ie. advertisements and facebook).  On the Nexus 7, everything is suspending just fine.  However, on the HTC phone, the activity suspends and exits, which causes the app to have a “reloading from beginning” effect.  This also means that all of my post-processing from those activities doesn’t take place.  

Looking at the logs, there’s no differences that would cause this.  

Possibly could be an overloaded heap problem, because it’s an image-intensive game, but I don’t know.

Any ideas?  Thanks!

#2

Is anybody experienced a problem like this before?  I’ve tried scaling back my memory to use really low res graphics to see if that was the cause, but it isn’t.

Which makes me wonder:

Is Android 4.4.2 supported by Corona?

#3

We most certainly support 4.4.2.  I’ll ask engineering to chime in.   Can you verify what carrier your phone is on?

Rob

#4

Oh and what version of Corona SDK are you using?  Are you building with Enterprise or the normal Corona SDK build process?

Have you looked in your console log (adb logcat) to see if there are any errors on the device that’s not working correctly?

Can you try to build a simple test app to see if you can duplicate it?

Rob

#5

Hi Rob,

It’s one of those prepaid HTC phones that doesn’t have a plan or anything.  I am using the most recent daily build for Enterprise that was available on the 2nd.  

I looked at logcat, and there’s nothing to hint at what’s going wrong.   However,  I did a factory reset of the phone and installed the app cleanly, and it works fine on the phone now.  I’ve been trying to replicate the problem but was unable to.

I’m going to try a beta test with some of my users when the app is ready, to see if they’re experiencing that problem as well.  I’m going to assume that it was a random fluke.

Thanks!

#6

Under Android’s “Settings” screen, there is a “Developer option” named “Don’t keep activities”.  By default, it is unchecked… but if you do check it on, then you’ll see this behavior.  Navigating forward to another activity or pressing the Home button will destroy your activity.

So, you can reproduce this behavior by doing the following…

  1. Go to your Android device’s “Settings” screen.
  2. Tap on “Developer options”.  (Usually at the bottom of this list. Not normally listed unless you opted-in to it.)
  3. Check on the “Don’t keep activities” box.

Once you do the above, you’ll find that *all* activities will be destroyed when you leave them.  They’ll effectively restart when you return to them.  There is really nothing you can do about this at the native developer level and is a big problem for apps that depend on navigating forward to other activities.  Especially when the app depends on an onActivityResult() functionality, which used to be a big problem for native Facebook logins until Facebook changed their SDK to support displaying a native login window on top of the existing activity without leaving it.  Just one of those Android announces you have to live with.  Although, like I mentioned above, the “Developer options” screen is not normally displayed to end-users and this is not normally check-on by default.  So, it’s an edge case that’ll not happen to most end-users.

#7

Is anybody experienced a problem like this before?  I’ve tried scaling back my memory to use really low res graphics to see if that was the cause, but it isn’t.

Which makes me wonder:

Is Android 4.4.2 supported by Corona?

#8

We most certainly support 4.4.2.  I’ll ask engineering to chime in.   Can you verify what carrier your phone is on?

Rob

#9

Oh and what version of Corona SDK are you using?  Are you building with Enterprise or the normal Corona SDK build process?

Have you looked in your console log (adb logcat) to see if there are any errors on the device that’s not working correctly?

Can you try to build a simple test app to see if you can duplicate it?

Rob

#10

Hi Rob,

It’s one of those prepaid HTC phones that doesn’t have a plan or anything.  I am using the most recent daily build for Enterprise that was available on the 2nd.  

I looked at logcat, and there’s nothing to hint at what’s going wrong.   However,  I did a factory reset of the phone and installed the app cleanly, and it works fine on the phone now.  I’ve been trying to replicate the problem but was unable to.

I’m going to try a beta test with some of my users when the app is ready, to see if they’re experiencing that problem as well.  I’m going to assume that it was a random fluke.

Thanks!

#11

Under Android’s “Settings” screen, there is a “Developer option” named “Don’t keep activities”.  By default, it is unchecked… but if you do check it on, then you’ll see this behavior.  Navigating forward to another activity or pressing the Home button will destroy your activity.

So, you can reproduce this behavior by doing the following…

  1. Go to your Android device’s “Settings” screen.
  2. Tap on “Developer options”.  (Usually at the bottom of this list. Not normally listed unless you opted-in to it.)
  3. Check on the “Don’t keep activities” box.

Once you do the above, you’ll find that *all* activities will be destroyed when you leave them.  They’ll effectively restart when you return to them.  There is really nothing you can do about this at the native developer level and is a big problem for apps that depend on navigating forward to other activities.  Especially when the app depends on an onActivityResult() functionality, which used to be a big problem for native Facebook logins until Facebook changed their SDK to support displaying a native login window on top of the existing activity without leaving it.  Just one of those Android announces you have to live with.  Although, like I mentioned above, the “Developer options” screen is not normally displayed to end-users and this is not normally check-on by default.  So, it’s an edge case that’ll not happen to most end-users.