Sorry if I already asked you this, but...does testgles or testrendercopyex work as expected on this device?

No, both tests have the exactily the same behavior as the apps Sylvain and I developed.

The blackscreen occurs when I switch in landscape mode by adding a line to the manifest file / adding a line in the java file. In portrait everything works as expected.

I also opened this one :)
https://bugzilla.libsdl.org/show_bug.cgi?id=2248

It happens sometimes in IOS !

Daniel, does it look the same as what you see in XperiaE when it came back after off/on ? (see description of cards collumns, bottom card, background).

Created attachment 1451 [details]
Starting the app

Created attachment 1452 [details]
Starting the app, pressing home (running in background) and get into again by starting the app

Created attachment 1453 [details]
Starting the app, pressing power twice (running in background), slide to unlock to go into app again

It's a little bit different. Like we thought it's not a determinate problem.
On the Xperia E I get allways a blackscreen on start (see screenshot: "Starting the app").

I added screenshots, so that it's possible to make a comparison to the apple pics.

Yes I agree this looks different.


what I see : 
- pressing home (Background-Foreground) solves the issue !


Pressing the off/on seems to only make the rendering appears:
- I believe the renderer is created with wrong size.
- but the pipeline is correctly doing the 90deg rotation !

hum I am wrong with my last comment, please ignore it.

Ok. could you do the same screenshot with the Spider game ?

this seems stupid but the background is blit in a different way that it reflects the internals of SDL.

Absolutly the same behavior in spider.
My games has this behavior, too.
I don't add the screens here (because they contain no new informations).

So:

what I see : 
- pressing home (Background-Foreground) solves the issue !


Pressing the off/on seems to only make the rendering appears:
- I believe the renderer is created with correct size.
I draw to size with w=480 h=320. and it fits into the renderer window.
and the backgroung (on spider) fits also. (I use rect dst == NULL).
it take the full size inside the rendered.

- the pipeline is correctly doing the 90deg rotation !
but it is also scaling the image which is wrong!

If the problem exists in testgles, it's fairly safe to assume the problem does not lie in the Renderer code. Can you try a bulk approach to debugging by creating a debug version with SDL_Log statements across the SDL_egl.c and all the JAVA side functions? Maybe that will shed some light as to what's going on without access to the device.

Another question, are you changing the min or target SDK level? Do you see other apps having the same problem?

Could this be related? https://bugzilla.libsdl.org/show_bug.cgi?id=1849

here's two logcats

logcat_good_1.txt 
logcat_bad_1.txt

for the behavier on a working phone, and the one of Daniel.

* I screw-up the log of renderer.viewport{x/y/w/h}  h is always y for both log
* Maybe I miss some java function ?
* I put logs wherever I could ...
* trace the sendWindowEvent stuff

So far, the diff says :
- difference in depth_size and in ES_BIT
- onWindowFocusChanged is sent earlier

In my app.. for historical raison, dont know if it have any effect.
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);

I will remove that in the next log I guess.

And the manifest xml:
 <uses-sdk android:minSdkVersion="10" android:targetSdkVersion="19" />
 <uses-feature android:glEsVersion="0x00020000" />

Created attachment 1454 [details]
logcat good 1

Created attachment 1455 [details]
logcat bad 1

 I mess-up the logcat. wait again for new logcat please.

Maybe related: http://stackoverflow.com/questions/10310098/android-opengl-es-textures-showing-on-black-screen-on-some-samsung-devices ?

Thanks for this idea, but this doesn't help. 
Changing the glViewport on HTC does change the output like it should. On the Xperia E the blackscreen stays black.

I brought back a handy feature of the Java code here: https://hg.libsdl.org/SDL/rev/ba26f042e36d

It's unlikely that it is related to what you are seeing, but we are just poking in the dark anyway, so you may as well give it a try.

Created attachment 1457 [details]
logcat good 2

Created attachment 1458 [details]
logcat bad 2

Good catch about the eglChoose mecanism ! but it doesnt solve the issue !

Also, remember going to background and then foreground is solving the problem, 
so the configuration remains the same ?

Here the logcat of a full scenario. 

we just do : 
start
- wait (the eglSwapBuffers)
- go to Background
- go to Foreground
- wait (the eglSwapBuffers)


"Logcat good 2 and background foregound" is with my device
and "bad" is with the XperiaE of Daniel.

There almost no difference

But we can notice during the resuming, the behavior is a little bit different :
"android_egl_context_restore" appears between "there1" and "there2". 

so the function with the logging :

 324 /* Resume */
 325 void Java_org_libsdl_app_SDLActivity_nativeResume(
 326                                     JNIEnv* env, jclass cls)
 327 {
 328     __android_log_print(ANDROID_LOG_VERBOSE, "SDL", "nativeResume()");
 329     SDL_Log("MyDebug : %s Android_Window=%p", __func__, Android_Window);
 330 
 331     SDL_Log("MyDebug : %s WILL ENTER FOREGROUND", __func__);
 332     SDL_SendAppEvent(SDL_APP_WILLENTERFOREGROUND);
 333     SDL_Log("MyDebug : %s WILL DID FOREGROUND", __func__);
 334     SDL_SendAppEvent(SDL_APP_DIDENTERFOREGROUND);
 335 
 336 
 337     if (Android_Window) {
 338         /* Signal the resume semaphore so the event loop knows to resume and restore the GL Context
 339          * We can't restore the GL Context here because it needs to be done on the SDL main thread
 340          * and this function will be called from the Java thread instead.
 341          */
 342         SDL_Log("MyDebug : %s there1", __func__);
 343         if (!SDL_SemValue(Android_ResumeSem)) SDL_SemPost(Android_ResumeSem);
 344         SDL_Log("MyDebug : %s there2", __func__);
 345         SDL_Log("MyDebug : %s FOCUS_GAINED", __func__);
 346         SDL_SendWindowEvent(Android_Window, SDL_WINDOWEVENT_FOCUS_GAINED, 0, 0);
 347         SDL_Log("MyDebug : %s RESTORED", __func__);
 348         SDL_SendWindowEvent(Android_Window, SDL_WINDOWEVENT_RESTORED, 0, 0);
 349     }
 350 }


hope this helps

Given there's two threads at work here, it may be more helpful to run:

   adb logcat -v threadtime 

So it's easier to identify which lines come from which thread (and will probably help identify if there's some hidden timing problem)

Created attachment 1459 [details]
logcat good 3

Created attachment 1460 [details]
logcat bad 3

here it is. with the -v theadtime setting

I have additional informations. May be this helps to get this bug fixed.
I played arround with some options and found that if I enable in the developer options: Force GPU-Rendering (Use 2D-Hardwareaccelation in Apps) everthing works nice!

All use cases (see pics) works without a problem with this option on!

maybe this could help : http://developer.android.com/guide/topics/graphics/hardware-accel.html

Yes this fixes the problem :), so Gabriel should we add the line in the manifest of the android-project example of SDL?

Not a bad workaround at all...I do wonder if this has any side effects, specially on API level 10 devices.

I have no Android 2.x device here, so I can't test it :-/.

Just wondering, it seems there are severals workaround possible, from the url:

Application level
Activity level
Window level
View level

Which one should be used ?

Also. How comes this bug did not appear with the common egl ? Maybe HW acceleration was already activated when creating : khronos.egl objets ?  
If so, would it be possible that khronos were using implicitly the "windows/view" level solution. ?

It works on all levels, this are the options:
<application android:hardwareAccelerated="true" ...>
or
<activity android:hardwareAccelerated="true" />
or
getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
in the onCreate() method.

Ok, fixed here: https://hg.libsdl.org/SDL/rev/1e390ba95c43

Thanks!