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.

Can you provide a test case, does this happen in all devices, some indication on how to replicate?

It was doing the same thing on a Kindle Fire HD 7 and a Samsung Galaxy S3. The Kindle would also often crash without a useable backtrace when starting.

I couldn't reproduce either problem with a minimal test app. The main difference between that and my real app is that the latter uses a separate thread for rendering. SDL can cope with that on Linux and Windows if I use SDL_GL_MakeCurrent appropriately, but I guess SDL interacts with Android's window and GL context in ways I don't understand, preventing it from working the way I tried.

I've already got working code which uses more abstraction, with SDL for Windows and Linux and a separate framework for Android, so I'll just go back to that. I was hoping to be able to use SDL2 for "everything" to keep it simpler.

I'm not sure what the consequences of having a separate rendering thread is on Android, but it would be nice to be able to narrow down the problem anyway. Marking as won't fix for now, but feel free to reopen if you can provide a test case to reproduce the problem.

Thanks!

GL context handling in SDL on Android is a bit of a grey area. In Android you can either let Java take care of it for you or use EGL yourself on the native side. I'm not sure which approach SDL uses, whether I'm supposed to call SDL_GL_CreateContext when my app starts.

README-android.txt says SDL doesn't provide an event to tell you if the GL context is lost, so I thought I could work around this by destroying it manually in the filter for SDL_APP_WILLENTERBACKGROUND (or signalling the rendering thread to do so if threading) and restoring it in SDL_APP_DIDENTERFOREGROUND.

This seems to work in my test case without a separate rendering thread (but perhaps that was a bit of luck, because the filter may run in a separate thread?), but not with a separate rendering thread.

Might checking SDL_GL_GetCurrentContext after SDL_APP_DIDENTERFOREGROUND events work?

You shouldn't destroy the context, there's code in SDL to manage the context automatically on pause/resume, and it's a delicate balance between the Java and native threads.

Like with any SDL app, if you want to use a SDL context, you have to call SDL_GL_CreateContext.

While it's true that you don't get a message when the context is lost (yet), this shouldn't affect you except in corner cases.

If you want to play around with the tests SDL comes with (test/testgles2.c comes to mind), there's a script in build-scripts/androidbuild.sh that build those easily and are a good parameter to judge how SDL works in your system (and you'll also see there's little in there in terms of context management).

I've done some more experiments today. The thing that seems to stop SDL propagating the resume events is if I stop my rendering thread on WILLENTERBACKGROUND. If I leave the thread running I get the WILL/DIDENTERBACKGROUND events as expected.

However, although my app seems to be running normally again, the screen stays black, so I think something must have happened to the GL context to make it invalid in the rendering thread. So I tried forwarding the DIDENTERFOREGROUND event to the queue/main loop calling SDL_GL_GetCurrentContext and there calling SDL_GL_GetCurrentContext to cache the context in case it's changed, then SDL_GL_MakeCurrent(window, 0) to unbind it from that thread, then signalling the render thread to call SDL_GL_MakeCurrent with the context I just cached. But the screen still stayed blank :-(.

I'll try a different approach, leaving rendering on the main thread, but I can run my game logic in a new thread and forward events to that on a custom queue.

Rendering on the main thread is the recommended way to handle things for all platforms anyway.