Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android does not resume properly #806

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Android does not resume properly #806

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2013-03-30 11:36:04 +0000, Jonny D wrote:

Created attachment 1085
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.

On 2013-03-31 06:18:36 +0000, Philipp Wiesemann wrote:

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

On 2013-04-01 09:54:36 +0000, Gabriel Jacobo wrote:

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)

On 2013-04-01 10:57:23 +0000, Philipp Wiesemann wrote:

(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.

On 2013-04-08 17:09:02 +0000, Jonny D wrote:

(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).

On 2013-04-19 13:41:30 +0000, Gabriel Jacobo wrote:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant