We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1776

Summary: Android does not resume properly
Product: SDL Reporter: Jonny D <grimfang4>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: gabomdq, philipp.wiesemann
Version: HG 2.0   
Hardware: ARM   
OS: Android (All)   
Attachments: Fix for mIsPaused

Description Jonny D 2013-03-30 11:36:04 UTC
Created attachment 1085 [details]
Fix for mIsPaused

I found that the native events thread does not regain control when the app is resumed.  This is because onCreate() is called on resume on my device, which sets mIsPaused to false before startApp() releases the semaphore.  Attaching patch to move initialization of mIsPaused to the class definition scope.
Comment 1 Philipp Wiesemann 2013-03-31 06:18:36 UTC
If onCreate() is called "on resume" the reason may also be that "android:configChanges" in AndroidManifest.xml [1] does not included all handled changes for the active API level. This attribute may be used to prevent some cases of re-creating everything (for other cases the above patch may still be needed).

[1] http://developer.android.com/guide/topics/manifest/activity-element.html#config
Comment 2 Gabriel Jacobo 2013-04-01 09:54:36 UTC
Phillip, if that were the case, wouldn't Android destroy the entire activity along with SDL's thread, etc ?

Jonny, do you see the other messages coming through (onConfigurationChanged, onDestroy, onSaveInstanceState)
Comment 3 Philipp Wiesemann 2013-04-01 10:57:23 UTC
(In reply to comment #2)
> Phillip, if that were the case, wouldn't Android destroy the entire activity
> along with SDL's thread, etc ?

The reference to the thread is stored in static field with the Activity class and not the Activity object.
Comment 4 Jonny D 2013-04-08 17:09:02 UTC
(In reply to comment #2)
> Jonny, do you see the other messages coming through (onConfigurationChanged,
> onDestroy, onSaveInstanceState)

I do not get onConfigurationChanged, I do not get onDestroy (but I get surfaceDestroyed), and I do get onSaveInstanceState (before surfaceDestroyed).
Comment 5 Gabriel Jacobo 2013-04-19 13:41:30 UTC
I'm reading the docs here: http://developer.android.com/reference/android/app/Activity.html (See the graph under "Activity Lifecycle")

The fact that you are getting onSaveInstanceState and then onCreate seems to imply that Android is killing your app's and recovering it's view resource: http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)
If that's the case, there should be an onStop call in there, can you verify?

Now my question is, after the onStop call...is it "good etiquette" to let the SDL thread keep it's resources (malloc'd stuff, OpenGL textures, etc), or would Android eventually kill the app if we hold on to those resources? (the whole mechanism seems to be triggered on low memory situations).

Anyway, I've applied the patch here http://hg.libsdl.org/SDL/rev/99d6803195fe as it seems a good fix, but I suspect there may be more that we need to do.