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 - Android does not resume properly
Summary: Android does not resume properly
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: ARM Android (All)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-30 11:36 UTC by Jonny D
Modified: 2013-07-06 16:38 UTC (History)
2 users (show)

See Also:

Attachments
Fix for mIsPaused (794 bytes, application/octet-stream)
2013-03-30 11:36 UTC, Jonny D 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.