I have exported some Lock/Unlock API for android, can you try to use it:
https://hg.libsdl.org/SDL/rev/50d0c0ade376


should do:

Lock()
CreateWindow()
create GL context()
CreateRenderer()
Unlock()

something like:


extern void Android_ActivityMutex_Lock(void);
extern void Android_ActivityMutex_Unlock(void);

Android_ActivityMutex_Lock();

then:

 if(!(win = SDL_CreateWindow(NULL, 0,0, w, h, flags)))
    {
        SDL_Log("[!] can't create Window %s\n", SDL_GetError());
        exit(-1);
    }
    SDL_Log("Window created");
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

    ctx = SDL_GL_CreateContext(win);
    SDL_Log("Got context");

    SDL_Renderer *ren = NULL;
    ren = SDL_CreateRenderer(win, -1, SDL_RENDERER_ACCELERATED);
    if (ren == NULL){
        SDL_Log("[!] can't create Renderer %s\n", SDL_GetError());
        return 1;
    }


then 

Android_ActivityMutex_Unlock();

the code with locks worked fine

ok!

can you also try this variant:

Android_ActivityMutex_Lock();
    ctx = SDL_GL_CreateContext(win);
Android_ActivityMutex_Unlock();



Can you also try your other issues with this ?

> can you also try this variant:

that variant crashes same way as without locks

> Can you also try your other issues with this ?

Will try tomorrow

Checked my other issues, one of them (EGL_BAD_SURFACE) can be fixed wrapping everything with this lock.

What's happening is that various operations (CreateWindow, CreateGLContext, CreateRenderer) can only be done while the Android SurfaceView is in created state, otherwise bad things happen.

There at least to way no to be in this bad configuration:
1/ When you press home button, app goes into Pause. That can happen, but this needs to be really quick when app starts.
2/ If you set the GL ARGB Attribute to 8888, because it reconfigures the SurfaceView for 8888: it goes into various states: surfaceCreated/surfaceChanged/surfaceDestroyed-*paused*-surfaceCreated.

Moreover: it goes to pause, but at that time, application isn't polling SDL events, so it can't handle APP{WILL,DID}ENTER{BACK,FORE}GROUND events.

( In fact, all SDL applications are written like:
Init, CreateWindow, CreateRenderer, PollEvents Loop.
Whereas they should be written like:
Init, PollEvents Loop, CreateWindow, CreateRenderer )


Solution:

I am not sure if it's really need to reconfigure the SurfaceView (2). 
( that was the modification https://hg.libsdl.org/SDL/file/5cbf6472a916/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java#l1138 )
I would say no, I see no difference with this, but it might be / it makes sense with the documentation.

As fix, we could remove this 2/, but since it can go in pause with 1/, it needs a fix anyway.
I see some kind of wait-for-the activity-to-be-in-running-state.


Can you add this function in src/core/android/SDL_android.c


void Android_ActivityMutex_Lock_Running() {
retry:
    
    SDL_LockMutex(Android_ActivityMutex);

    int pauseSignaled = SDL_SemValue(Android_PauseSem);
    int resumeSignaled = SDL_SemValue(Android_ResumeSem);

    if (pauseSignaled > resumeSignaled) {
        SDL_UnlockMutex(Android_ActivityMutex);
        SDL_Delay(50);
        goto retry;
    }    
}



And re-write the code:


Android_ActivityMutex_Lock_Running();
SDL_CreateWindow()
Android_ActivityMutex_Unlock();

...

Android_ActivityMutex_Lock_Running();
ctx = SDL_GL_CreateContext(win);
Android_ActivityMutex_Unlock();

...

Android_ActivityMutex_Lock_Running();
SDL_CreateRenderer()
Android_ActivityMutex_Unlock();


I have tested this idea and it works. It would hidden in the CreateWindow/Context/Renderer
Not sure If this is acceptable.

yes, it fixed the issue.

I've made some patch of it: can you try it, with your original code ?

https://hg.libsdl.org/SDL/rev/dd9169424181

This patch seems to fix this particular case, but the complex kivy app still crashes a bit later after startup. I suspect that other window manipulation functions had to be treated with lock as well. I am yet to figure out how to get the proper stacktrace

just some thoughts:
- is this a real crashes or black screen ?
- do you have a specific user inter-action like: going background/foreground ?

it is a crash, it happens right after app start, without any user action:
F/libc    (25156): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x9c in tid 25156 (SDLActivity)

But I am unable to retrieve the full stacktrace - how pure SDL app achieves that being logged on crash?

Look strange, can you see the full adb log ? Or put some more traces with SDL_Log() ?


Maybe clean all / rebuild. Sometimes Java activity builds incorrectly and app never starts.

full log:

06-29 17:14:14.419 I/python  (25156): [INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
06-29 17:14:14.959 I/python  (25156): [INFO   ] [Window      ] Provider: sdl2
06-29 17:14:15.449 D/wpa_supplicant( 9577): wlan0: Control interface command 'SIGNAL_POLL'
06-29 17:14:15.479 E/libEGL  (25156): validate_display:255 error 3008 (EGL_BAD_DISPLAY)
06-29 17:14:15.479 V/SDL     (25156): setOrientation() orientation=-1 width=1080 height=1920 resizable=true hint=
06-29 17:14:15.489 V/SDL     (25156): surfaceDestroyed()
06-29 17:14:15.639 D/FTLogger(12544): FULLTRACE:->send rawBody type: 0x13, time:1561817655647, Body:[B@23ab1d04
06-29 17:14:15.639 V/Fulltrace-native(12544): appendBytesBody byte array
06-29 17:14:15.999 V/SDL     (25156): nativePause()
06-29 17:14:16.019 I/python  (25156): [INFO   ] [GL          ] Using the "OpenGL ES 2" graphics system
06-29 17:14:16.019 I/python  (25156): [INFO   ] [WindowSDL   ] No running App found, exit.
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] Backend used <sdl2>
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] OpenGL version <b'OpenGL ES 3.1 V@124.0 (GIT@I041b18199e)'>
06-29 17:14:16.029 V/SDL     (25156): surfaceCreated()
06-29 17:14:16.029 V/SDL     (25156): surfaceChanged()
06-29 17:14:16.029 V/SDL     (25156): pixel format RGBA_8888
06-29 17:14:16.029 V/SDL     (25156): Window size: 1080x1845
06-29 17:14:16.029 V/SDL     (25156): Device size: 1080x1920
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] OpenGL vendor <b'Qualcomm'>
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] OpenGL renderer <b'Adreno (TM) 405'>
06-29 17:14:16.029 V/SDL     (25156): nativeResume()
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] OpenGL parsed version: 3, 1
06-29 17:14:16.029 I/python  (25156): [INFO   ] [GL          ] Texture max size <16384>
06-29 17:14:16.039 I/python  (25156): [INFO   ] [GL          ] Texture max units <16>
06-29 17:14:16.199 I/python  (25156): [INFO   ] [Window      ] auto add sdl2 input provider
06-29 17:14:16.349 I/python  (25156): [INFO   ] [Window      ] virtual keyboard not allowed, single mode, not docked
06-29 17:14:16.609 V/SDL     (25156): surfaceChanged()
06-29 17:14:16.609 V/SDL     (25156): pixel format RGBA_8888
06-29 17:14:16.609 V/SDL     (25156): Window size: 1080x1920
06-29 17:14:16.609 V/SDL     (25156): Device size: 1080x1920
06-29 17:14:17.089 I/python  (25156): [INFO   ] [Text        ] Provider: sdl2
06-29 17:14:18.459 D/wpa_supplicant( 9577): wlan0: Control interface command 'SIGNAL_POLL'
06-29 17:14:20.159 I/python  (25156): [WARNING] [Factory     ] Ignored class "NiceTextInput" re-declaration. Current -  module: None, cls: None, baseclass: TextInput, filename: None. Ignored -  module: None, cls: None, baseclass: TextInput, filename: None.
06-29 17:14:20.469 I/python  (25156): [WARNING] [Lang        ] constants.kv has already been included!
06-29 17:14:20.999 I/python  (25156): [INFO   ] [GL          ] NPOT texture support is available
06-29 17:14:21.329 I/python  (25156): [WARNING] [Lang        ] constants.kv has already been included!
06-29 17:14:22.749 I/python  (25156):  2019-06-29 17:14:22.760 | INFO     | __main__:build:107 - Build started
06-29 17:14:22.759 I/python  (25156): [WARNING] [Lang        ] constants.kv has already been included!
06-29 17:14:22.789 I/python  (25156): [WARNING] [Base        ] Unknown <android> provider
06-29 17:14:22.789 I/python  (25156): [INFO   ] [Base        ] Start application main loop
06-29 17:14:22.789 I/python  (25156): [INFO   ] [Base        ] Leaving application in progress...
06-29 17:14:23.179 I/python  (25156): Python for android ended.
06-29 17:14:23.869 F/libc    (25156): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x9c in tid 25156 (SDLActivity)

rebuild does not seem to do anything

In(In reply to someuniquename from comment #14)
> rebuild does not seem to do anything

Indeed this isn't the Java issue, because it starts.

Can you add traces in the lock/unlock that were added.
You can also comment out their implementation...

Or could this be python that crashes?

when python crashes, it prints traceback as in issue https://bugzilla.libsdl.org/show_bug.cgi?id=4681
so the crash probably comes from java code

I meant python itself, not the script.
In Java also it produces a stacktrace.

Compile in debug?

Add some traces. Try to see more logs.

Provide me an APK, but I very likely wont see more.

Let me test it for a while, I am failing to reproduce it after full cleanup and rebuild.

ah, i added more trace prints and see the error is thrown sometimes right before kivy app exits normally:
07-01 08:32:07.060 I/python  (24003):  2019-07-01 08:32:07.066 | INFO     | __main__:async_run:225 - App about to exit
07-01 08:32:07.060 I/python  (24003):  2019-07-01 08:32:07.069 | INFO     | __main__:async_run:227 - App stopped
07-01 08:32:07.070 I/python  (24003):  2019-07-01 08:32:07.075 | DEBUG    | paradox.uix.screens.formlist_screen:wrapped:236 - hide loader
07-01 08:32:07.080 I/python  (24003): App stopped without error
07-01 08:32:07.080 I/python  (24003): Python for android ended.
07-01 08:32:08.040 F/libc    (24003): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x9c in tid 24003 (SDLActivity)

So this is probably another issue

Here is the apk: https://drive.google.com/file/d/1l-3X8rMVrL_jlSz37l1b47IzEFEOph0J/view?usp=sharing

it exits normally right after start, because of a kivy issue (app is paused bit too early). But what is concerning is that SDL throws SIGSEGV after that

I tried the apk and dont get the error:

 07-01 09:13:14.300 20864 20922 I python  : App stopped without error
 07-01 09:13:14.300 20864 20922 I python  : Python for android ended.

but no "Fatal signal 11 (SIGSEGV)"

but I notice, I don't get the normal exit of the SDLActivity.
Is python calling exit() ? It should just return from main, 
so that the SDLActivity terminates normally and tells a message like "SDLActivity ends with nb error(s)".

Unfortunately I do not have deep knowledge about kivy python-for-android internals, but i think it extends SDLActivity with this: https://github.com/kivy/python-for-android/blob/develop/pythonforandroid/bootstraps/sdl2/build/src/main/java/org/kivy/android/PythonActivity.java

And it launches C app which launches python interpreter, then exits normally from main()

Add traces, in all functions to see where/when it crashes ..

like 
Log.v(TAG, "SDL start function ...");
Log.v(TAG, "SDL end function ...");


also in this block of code, which seems strange:

            // Launch app if that hasn't been done yet:
            if (mActivity.mHasFocus && (
                    // never went into proper resume state:
                    mActivity.mCurrentNativeState == NativeState.INIT ||
                    (
                    // resumed earlier but wasn't ready yet
                    mActivity.mCurrentNativeState == NativeState.RESUMED &&
                    mActivity.mSDLThread == null
                    ))) {
                // Because sometimes the app will get stuck here and never
                // actually run, ensure that it gets launched if we're active:
            mActivity.onResume();
          }

Moving all the remaining target-2.0.10 bugs to target-2.0.11. If these still aren't resolved when 2.0.11 ships, we should probably remove the keyword altogether.

--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.