IssueTracker

Hi, sorry for the long wait, and thanks for providing the app to repro it.

I did successfully repro the problem with Swiftshader on one test run, but couldn't repro the problem in further runs. It seems timing related. We have had some fixes for our emulator / system images recently that are timing sensitive.

I was not able to reproduce the problem with hardware gpu though.

Here are some things to try:

1. Try running with the latest emulator (26.1.4) and system image (api 22 google apis revision 16)
2. Try using Mesa (even though we've deprecated it) (works on Linux/Windows):
cd $ANDROID_SDK_ROOT/emulator; LD_LIBRARY_PATH=./lib64/gles_mesa objs/emulator -avd api22 -gpu host -feature -GLESDynamicVersion
3. Try using Swiftshader on a GLESv3-capable image (I did not repro it on those sorts of images (though I've only reproed it once)); latest revisions of API 24, 25 or 26.

(oops, "./emulator" not "objs/emulator")

Hi!

It took a while to try everything ;)

ad 1.) We've tried the latest emulator 26.1.4 from canary with latest image, but error still occurs :(

ad 2.) We couldn't run the emulator with the suggested command, got the error:
  unknown option: -feature
  please use -help for a list of valid options

On Windows machine (with real GPU):
  When we remove the part "-feature -GLESDynamicVersion", the emulator starts, but we guess it's then running with regular host gpu.
  At least the emulator feels like running as fast and smooth as calling "emulator -gpu host -avd api22".
  So we're not sure whether it's really using mesa then ... How to find out which kind of gpu emulation is really used in the running emulator?

We couldn't get it running yet on our CI - without unknown option "-feature -GLESDynamicVersion" we get:
  sh: lspci: command not found
  Error: unable to open display
  -> Due to vacations and permissions, we currently can't update our docker base image to install pciutils ... might give it a try next week.

ad 3.) Got the same issue on all suggested API levels.
  We improved the sample app by updating all dependencies and adding an androidTest, which can just be started and watch it fail.
  --> testLoginLoop
  The test does the following:
   - check if the webview is available
   - reload the page
   - check again if the webview is available
   - check if some content inside the webview is available
   - press back (so the activity is stopped)
   - start an intent to reorder the activity to front
   --> repeat
   After some time, the test suddenly fails because the webview isn't showing anything anymore.
   It varies on how long the test has to run to fail, but this behaviour was reproduced on all tested API versions (22, 24, 26) on Windows with swiftshader (connecting via remote desktop to a real machine and starting emulator from Android Studio forces swiftshader - might also be Angle ... here comes the question again: How to find out which kind of gpu emulation is really used in the running emulator?)

Thanks for the findings! In reference to:

How to find out which kind of gpu emulation is really used in the running emulator?

Record logcat from the beginning of device startup. Early on, there will be lines from SurfaceFlinger showing the renderer used. You can search for the string "OpenGL". The renderer used should show up then.

If you're on a Windows machine, you can just issue -gpu mesa.

Ahh - there it is written :)

So we verified the actual GPU used and found out 2 things ...
08-29 07:12:25.377 1326-1326/? I/qemu-props: received: ro.opengles.version=131072
08-29 07:12:28.162 1328-1328/? I/SurfaceFlinger: Client API: OpenGL_ES
08-29 07:12:28.176 1328-1328/? I/SurfaceFlinger: OpenGL ES informations:
08-29 07:12:28.176 1328-1328/? I/SurfaceFlinger: version   : OpenGL ES 2.0 SwiftShader 3.3.0.2

1.) There was some wrong emulator version on the path of the windows machine...
  android-sdk/tools/emulator.exe vs android-sdk/emulator/emulator.exe

  With the proper emulator, mesa and angle can be started. ;)
  Couldn't reproduce the issue with mesa or angle GPU.
  When switching again to swiftshader (OpenGL ES 2.0), the issue appears again.

2.) The release notes for 26.1.2 at https://developer.android.com/studio/releases/emulator.html#26-1 stated:
  "OpenGL ES 3.x is now enabled by default for system images and host GPUs that support OpenGL ES 3. Currently, only Android O (API level 26) and Windows/Linux hosts support OpenGL ES 3.
  If you experience problems with OpenGL ES 3, add the line GLESDynamicVersion = off in ~/.android/advancedFeatures.ini."

  Well, this doesn't seem to be true ... with a regular updated installation, it was just starting OpenGL ES 2.0...
  So we created the file "~/.android/advancedFeatures.ini" and explicitly set "GLESDynamicVersion = on" (expected to be the same as the parameter option "-feature -GLESDynamicVersion" which still doesn't work, even with the proper emulator.exe)

  When starting the emulator again, it's now properly using OpenGL ES 3.0
08-29 08:36:41.606 1344-1344/? I/qemu-props: received: ro.opengles.version=196608
08-29 08:36:43.106 1346-1346/? I/SurfaceFlinger: Client API: OpenGL_ES
08-29 08:36:43.114 1346-1346/? I/SurfaceFlinger: OpenGL ES informations:
08-29 08:36:43.114 1346-1346/? I/SurfaceFlinger: version   : OpenGL ES 3.0 SwiftShader 3.3.0.2


Now we could successfully verify your suggested step 3!
3. Try using Swiftshader on a GLESv3-capable image (I did not repro it on those sorts of images (though I've only reproed it once)); latest revisions of API 24, 25 or 26.

We ran our testLoop for a while and the webview always loaded perfectly.
So we guess, it's fine now ... although still waiting for the results of our CI (also needed to set "GLESDynamicVersion = on") 👍👍


So, beside the actual issue, there were those problems with verification:
 - know the real version of what's beeing tested ^^
 - updating the android sdk didn't properly clear/update the installation and left an old emulator executable in the tools
 - advancedFeatures.ini wasn't created automatically with the value "GLESDynamicVersion = on" (and emulator is not automatically using this value as fallback, as stated in the release notes)

Wow, this is really awesome info, thanks so much! So it's narrowed down to Swiftshader, OpenGL ES 2.0 mode. Nicolas, can you take a look?

Yeah we should be more clear on the ~/.android/advancedFeatures.ini part. It is a file that is not created by default, and is meant to hold user overrides of feature flags. However, there is a $ANDROID_SDK_ROOT/emulator/lib/advancedFeatures.ini that holds the default settings that are then overriden from:

1. the ~/.android/advancedFeatures.ini
2. server side feature flags downloaded from the internet (but (1) takes priority)

The emulator.exe in path is quite unfortunate, especially in light of the move from tools to emulator folder and how an old emulator.exe is left there. We've actually had a lot of users have the same problem with emulator.exe in $PATH, but pointing to tools/emulator.exe, so they are not be able to use the new GPU backends...Perhaps tools/emulator should be a script to launch the newer emulator.exe instead.

Sorry for the delay in getting to this. It's not clear to me from #6 if this is actually still an issue? FWIW I can't seem to replicate the issue with the emulator version 26.1.4, which comes with Android Studio 3.0 Beta 4, on Linux.

Hi!

I guess there is still an answer missing from our side :)
We still had the problem with 26.1.4, but were happy with our workaround of using the old emulator :)

We tested a newer emulator from time to time, but still had this issue with various versions of the emulator.
Meanwhile its version 27.2.9 and it seems to be fixed :)
We can't really say with which version the problem actually got fixed (and if it was the emulator or the image), but we are happy now!

06-05 15:47:49.803  1315  1315 I SurfaceFlinger: OpenGL ES informations:
06-05 15:47:49.803  1315  1315 I SurfaceFlinger: vendor    : Google (Google Inc.)
06-05 15:47:49.803  1315  1315 I SurfaceFlinger: renderer  : Android Emulator OpenGL ES Translator (Google SwiftShader)
06-05 15:47:49.803  1315  1315 I SurfaceFlinger: version   : OpenGL ES 2.0 (OpenGL ES 3.0 SwiftShader 4.0.0.1)

So from our side this issue is done and could be closed.

Thanks!

Thanks for confirming this got fixed! Several WebView related issues got fixed in recent months, so I assume one of them was also the cause of this issue.

Frank, is any follow-up needed here, e.g. to ensure we have a test for it? You also seemed to have some suggestions for cleanup in #7.

It could have been a webview side fix, but we've also auto enabled more users to run with GLES 3.0. Marking this as fixed for now. Webview tests would ideally start with a host side goldfish-opengl test framework + fake Android graphics so we can run some rendering part of webview end to end.