Snapshot not restored on applicationResume for Android (4.3)

More information.  We can confirm that calling display.save() on applicationSuspend will result in the application screen rendering black on applicationResume.  This was confirmed on Samsung Galaxy Tab 10.1 running Android 4.0.4 (Tegra 2) and the Tabeo e2 running Android 4.2.2 (Tegra 3).  I’m not sure if this is a chipset issue or not.

Since display.save() is effectively the only way to save a snapshot so we can recreate the user experience on resume (when using the discard canvasMode because we have to for performance), we are completely blocked trying to pass the Samsung Seller app certification process.

Specifically, Samsung states (as a top 10 reason for app certification failure):

Problems in the Background mode

  1. Pause/Resume issues
  • Functions are not resumed when it comes to the Foreground Mode.
  • Not be resumed but executed from start page when it comes to the Foreground Mode from the Background Mode.
                        
  1. Functional issues
                          
  • UI errors are occurred when it comes to the Foreground Mode.

(http://developer.samsung.com/distribute/app-certification/top-10-failures-and-tips)

Currently our options are:

1)  Allow the user’s data to be corrupted by the suspend/resume process by doing nothing.

2)  Use display.save() and cause the screen to render black

3)  On applicationResume, restart the application.

4)  On applicationResume, restart the module (resulting in user data loss)

Options 1-3 will cause the application to get immediately rejected by Samsung.

We’re going to try using Option 4 but I’m pessimistic about the results.

On January 13th, Walter wrote in this thread  that a fix was coming soon.  We look forward to testing it!

Terry

@tschussler, just a quick correction. That was a different black screen issue that was fixed as explained here (http://forums.coronalabs.com/topic/42581-black-screen-loading-hello-world-sample-app-on-android-20132099/?p=225247). 

Also, I searched the bugbase for “display.save” and your Android black screen issue did not come up, which explains why it’s not on our radar…

@walter, thanks for the correction.  It was a little challenging to dig up the information that I did and I apologize for any confusion.

We just finished creating a reproducible code sample and we’re filing a ticket on this issue.  Thanks for you and your team’s awesome hard work - we really appreciate it!

OK, for everyone’s benefit:

You cannot call display.save() during applicationSuspend because the OpenGL context is destroyed by the time your code gets called.  This is a limitation of the Android OS and not Corona’s fault.

We are testing a workaround approach which involves calling display.save() during user idle time or after user touch events that affect the data we want to save.  Performance might not be acceptable here but we’ll give it a whirl and report back our success (or failure) to the community.

@nikraver:

We’re experiencing this exact same issue.  Were you able to determine a solution that worked to prevent the black screen issue on applicationResume?

This bug is still present, for us we’re getting it specifically on the Galaxy Tab 10.1. Any updates on this? @nikraver - have you been able to solve this issue or work around it in any way?

No, have tried every possible scenario and the only workaround was to redirect the user to the main menu on applicationResume.

Note: The app was rejected on Samsung due to this “workaround”

More information.  We can confirm that calling display.save() on applicationSuspend will result in the application screen rendering black on applicationResume.  This was confirmed on Samsung Galaxy Tab 10.1 running Android 4.0.4 (Tegra 2) and the Tabeo e2 running Android 4.2.2 (Tegra 3).  I’m not sure if this is a chipset issue or not.

Since display.save() is effectively the only way to save a snapshot so we can recreate the user experience on resume (when using the discard canvasMode because we have to for performance), we are completely blocked trying to pass the Samsung Seller app certification process.

Specifically, Samsung states (as a top 10 reason for app certification failure):

Problems in the Background mode

  1. Pause/Resume issues
  • Functions are not resumed when it comes to the Foreground Mode.
  • Not be resumed but executed from start page when it comes to the Foreground Mode from the Background Mode.
                        
  1. Functional issues
                          
  • UI errors are occurred when it comes to the Foreground Mode.

(http://developer.samsung.com/distribute/app-certification/top-10-failures-and-tips)

Currently our options are:

1)  Allow the user’s data to be corrupted by the suspend/resume process by doing nothing.

2)  Use display.save() and cause the screen to render black

3)  On applicationResume, restart the application.

4)  On applicationResume, restart the module (resulting in user data loss)

Options 1-3 will cause the application to get immediately rejected by Samsung.

We’re going to try using Option 4 but I’m pessimistic about the results.

On January 13th, Walter wrote in this thread  that a fix was coming soon.  We look forward to testing it!

Terry

@tschussler, just a quick correction. That was a different black screen issue that was fixed as explained here (http://forums.coronalabs.com/topic/42581-black-screen-loading-hello-world-sample-app-on-android-20132099/?p=225247). 

Also, I searched the bugbase for “display.save” and your Android black screen issue did not come up, which explains why it’s not on our radar…

@walter, thanks for the correction.  It was a little challenging to dig up the information that I did and I apologize for any confusion.

We just finished creating a reproducible code sample and we’re filing a ticket on this issue.  Thanks for you and your team’s awesome hard work - we really appreciate it!

OK, for everyone’s benefit:

You cannot call display.save() during applicationSuspend because the OpenGL context is destroyed by the time your code gets called.  This is a limitation of the Android OS and not Corona’s fault.

We are testing a workaround approach which involves calling display.save() during user idle time or after user touch events that affect the data we want to save.  Performance might not be acceptable here but we’ll give it a whirl and report back our success (or failure) to the community.