Would it be possible to circumvent that semaphore in the Android build by relying on the Android event filter(for stuff like SDL_APP_TERMINATING etc.) that I have loaded in place for those? Keep a flag in the main thread(the one that calls SDL_pollEvent which ends up at SDL_Android_PumpEvents, which would normally call a semaphore that locks things up until the app is activated once again(with proper texture context saving required).

So, could I instruct the filter(which redirects to a semaphore-protected part of code that's also called in the main thread when SDL_pollEvent returns 1), thus:

The main thread checks a semaphore-protected flag that tells not to call SDL_pollEvent(thus allowing the main thread to continue onwards during having entered the background), while the filter function calls the input handler for the duration between the entering of the background and returning to the foreground, thus preventing the queue from overflowing and the application becoming non-blocked during minimalization?

Or would that method cause problems with SDL2?

Maybe modify it(when some support flag is set through hints) to perform the whole background entering-foreground entering synchronization to be performed before sending the app has entered the foreground again, instead of handling it when entering the background? That way, the app(like a music player) can run in the background, entering foreground restoring context(video) only?

This should now be really easy to implement: 

Remove BLOCK_ON_PAUSE define, 
renames Android_PumpEvents functions to Android_PumpEvents_Blocking and Android_PumpEvents_NonBlocking

https://hg.libsdl.org/SDL/file/a7d52e2db27a/src/video/android/SDL_androidevents.c

update  
https://hg.libsdl.org/SDL/file/a7d52e2db27a/src/video/android/SDL_androidvideo.c
to initialize with correct function and add an api to change:
device->PumpEvents = Android_PumpEvents

(In reply to Sylvain from comment #3)
> This should now be really easy to implement: 
> 
> Remove BLOCK_ON_PAUSE define, 
> renames Android_PumpEvents functions to Android_PumpEvents_Blocking and
> Android_PumpEvents_NonBlocking
> 
> https://hg.libsdl.org/SDL/file/a7d52e2db27a/src/video/android/
> SDL_androidevents.c
> 
> update  
> https://hg.libsdl.org/SDL/file/a7d52e2db27a/src/video/android/
> SDL_androidvideo.c
> to initialize with correct function and add an api to change:
> device->PumpEvents = Android_PumpEvents

Sounds pretty simple. Then base what Android_PumpEvents_(Non)Blocking to use on a simple environment setting(defaulting to Blocking for compatibility). Of course a good name for said environment variable might be just keeping it the same "SDL_ANDROID_BLOCK_ON_PAUSE"?

That BLOCK_ON_PAUSE define shouldn't have been as a define in the first place, since it's depending on the application, not SDL itself?

I for one am looking forward to seeing such functionality in a future SDL2 version, as it allows me to use the SDL2 code without having to modify it's code(besides the obvious library(SDL2_net in my case)). It also prevents common code bugs based on said setting(as people easily make mistakes typing code), so the less modding of SDL source code, the better?

With Environment variable I meant a simple SDL Hint.

I just stumbled across this, and this is a huge problem for my app:

it saves and the save may take a little longer (as in few seconds), so if the user presses save and tabs out, the save is BLOCKED and it hangs there until it's unloaded WITHOUT saving!!

So I just wanted to weigh in that it would be awesome if this could be at least be deactivated with a hint/without recompiling. However, I would even go as far as to suggest it shouldn't be enabled per default either, because this feature is highly counter-intuitive because it goes against everything that SDL2 does on all other platforms...

Just to clarify: if on desktop I want to save battery, I need to decrease polling in the background myself. (Which I do btw) Or use SDL_WaitEvent, if that one actually worked sanely:

This smells like a really hackish attempt to work around the (bad) limitation that SDL_WaitEvent doesn't actually block as it should, but instead polls internally.

Why not actually fix SDL_WaitEvent instead and just REMOVE this block on pause thing completely? Because isn't SDL_WaitEvent already SDL_PollEvent_Blocking? What's the purpose of complicating things with this weird setting if the API would actually already be there to support this properly without surprises?

Since I just realized this goes beyond what this ticket here asked for, I made a separate one here asking for the full removal of the option: https://bugzilla.libsdl.org/show_bug.cgi?id=4541

Do you want me to propose an API to switch dynamically the block on pause ?

(In reply to Sylvain from comment #9)
> Do you want me to propose an API to switch dynamically the block on pause ?

Yes please. What's your idea?

Created attachment 3728 [details]
patch

here's a patch, almost not test.
it would be probably better with a hint.
Currently you need to call Android_SetBlockingMode()

For what it's worth, we discussed this in python-for-android here: https://github.com/kivy/python-for-android/pull/1773 and have ended up with it being undecided about whether this should be enabled or not.

Having such a function or ideally a hint would resolve this issue fully and make life for us easier regarding that! So that would be really cool to have

Sylvain, can you add a hint for this?

Thanks!

Ok, this is added !
https://hg.libsdl.org/SDL/rev/d311fcb8066a
Please give a try !

You need to set it before SDL is initialized (e.g. before the video device choose the pumpevent function).

I'm not sure if we can always set it dynamically.

I tested the hint and set it to "0" before SDL_Init(), and it worked perfectly! Same effect as #define SDL_ANDROID_BLOCK_ON_PAUSE 0, but without any of the source code patching this time. Really awesome work, thanks!!

I also added it to my app, which now can properly continue running in the background(except audio). Thanks!

The update works properly like it's supposed to. I look forward to seeing this in an official update(e.g. version 2.0.10).