tazihad
commented
3 years ago No. Mine Just close automatically. Manjaro 5.8. Snaps install
Open Niek opened 3 years ago
tazihad
commented
3 years ago No. Mine Just close automatically. Manjaro 5.8. Snaps install
Niek
commented
3 years ago Direct APK links if anyone else wants to test:
supaplextor
commented
3 years ago I'm running today's beta/rolling snap and while other apps seem to be ok, chrome is a dud in anbox. I almost had a screenshot of two instances, one all black screen, the other - one tab, but unresponsive to anything else. Webview works (as bare bones yeah)
Niek
commented
3 years ago I tried the latest version as I had some hope that this commit by @jnnksdev would solve the EGL emulation issues, but still the same EGL_BAD_CONFIG errors.
Firefox Fenix is working fine on Anbox, and so is (the super outdated) webview as @supaplextor mentioned. It would be great if someone would have any ideas how to to get Chrome running.
jnnks
commented
3 years ago Inspecting the chromium source we can find the root of the error [ERROR:gpu_channel_manager.cc(749)].
The entry-point in Anbox might be eglCreateContext, but that is a shot in the dark.
If that is the case, then an Android image has to be rebuilt and published, which might take some time.
Niek
commented
3 years ago @jnnksdev that's indeed the place where the error occurs. The image that is used now is definitely fairly old. Would be it be a simple rebuild or does the code need to be synced with AOSP?
jnnks
commented
3 years ago This project did not see a lot of love lately, resulting in the old image. When having to deploy a new one it might make sense to go with a newer Android version than of 7.1.1 . These changes are beyond creating small PRs though. At least I can only spend more time on big questions earliest december.
I'll do more research about the topic on the weekend.
jnnks
commented
3 years ago OK, so my suspicion was correct. eglCreateContext is called (thrice ?) before the first ERROR shows up.
Considering that it has been called once without issues, I'm not sure why it has been failing other times.
Interesting to note would be E libEGL : validate_display:99 error 3008 (EGL_BAD_DISPLAY) EGL complaining about a bad display. That may cause the issue instead.
Niek
commented
3 years ago Thanks for investigating @jnnksdev! The display error seems to be coming from here: https://github.com/anbox/anbox/blob/7f1bfaf90de1f808d4ce8f49ef050120c5c8d1ef/android/opengl/system/egl/egl.cpp#L94-L103
I wonder if this could be fixed with an updated Android base image.
Fincer
commented
3 years ago Hi,
@jnnksdev thank you for the verbose log output. And thanks @Niek for emailing me.
Default Anbox WebView application (org.chromium.webview_shell) gives the same validate_display:99 error 3008 (EGL_BAD_DISPLAY) error but still renders the web content fine (I tested it). Therefore, I doubt the relevant error is hinted by eglCreateContext(921): error 0x3005 (EGL_BAD_CONFIG) instead. This does not exclude the possibility these two are related, however.
My Anbox adb shell informs OpenGL version as follows:
> adb shell dumpsys SurfaceFlinger |grep OpenGL
GLES: Intel, Mesa Intel(R) UHD Graphics 630 (CFL GT2), OpenGL ES 2.0
logcat output of the default Anbox WebView app (org.chromium.webview_shell) which still successfully renders a web page:
Chromium output is same than posted in https://github.com/anbox/anbox/issues/1637#issuecomment-724003542. Snipped logcat part. Fails to render a web page:
L1 | 11-23 18:46:58.867 733 749 E chromium: [ERROR:shared_image_stub.cc(417)] SharedImageStub: unable to create context
L2 | 11-23 18:46:58.867 733 749 E chromium: [ERROR:gpu_channel.cc(449)] GpuChannel: Failed to create SharedImageStub
L3 | 11-23 18:46:58.868 733 749 E EGL_emulation: tid 749: eglCreateContext(919): error 0x3005 (EGL_BAD_CONFIG)
L4 | 11-23 18:46:58.868 733 749 E chromium: [ERROR:gl_context_egl.cc(233)] eglCreateContext failed with error EGL_BAD_CONFIG
L5 | 11-23 18:46:58.868 733 749 E chromium: [ERROR:gpu_channel_manager.cc(711)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
...Referred chromium source code parts:
As a quick test, I commented out the relevant egl.cpp source code (shown below) from an anbox-git Linux package. With this test I wanted to see where the error actually comes from, and how does commenting out the code affects application behavior.
egl.cpp source code lines 917-920 say as follows:
// Currently only support GLES1 and 2
if (version != 1 && version != 2) {
setErrorReturn(EGL_BAD_CONFIG, EGL_NO_CONTEXT);
}where the line 919 is where the logcat output refers to (I highly suspect).
However, the error message error 0x3005 (EGL_BAD_CONFIG) was still there with the same line 919 reference. I suspect the error originates from precompiled Android image (7.1.1) contents. For those who don't know: Android image file requires Anbox source code sections to be used during image creation process. As I excluded the mentioned egl.cpp code part from installed anbox-git Linux package but not from the Android image, the image was the only potential source for the error message. However, I didn't actually re-compiled the image file for now, so there is no absolute 100% certainty.
Basically, I could compile a new Android image especially for this issue, but just commenting out code section 917-920 does not resolve the issue, anyway.
To sum up, I didn't test the issue further but I suspect it has something to do with OpenGL versions that Anbox uses/supports/registers to Chromium or vice versa. I don't know, but someone might have time to investigate this issue further.
Further code & log analysis is required. For instance:
Which part in Chromium actually/ultimately fails and why (reasons behind the failure)?
Does Anbox use correct OpenGL version for this application? If not, why? If it does, then why doesn't Chromium pick it up or fails to load the content?
Which part of the rendering process does fail?
Why does org.chromium.webview_shell succeed in content loading but a third-party Chromium application fails?
Not sure if the following is relevant. However, this is from an early Anbox boot process:
Fincer
commented
3 years ago I decided to re-compile Android image with the code sections 908-909 and 917-920 commented out in egl.cpp. The application doesn't still work but the logcat output differs, as expected. The commented out code section basically checks whether to return EGL_BAD_CONFIG if GLES version is not OK, so I just disabled this check procedure. I applied the same code modification to my anbox-git Linux package.
And, as usual, that log output generates an endless loop.
If anyone is interested, I uploaded the Android image to my web server. The image file has audio timing patchset applied, and this code modification. You find the image file here.
This issue is an interesting one and may have correlation: GitHub - VirtualGL/virtualgl - Support for recent chrome/chromium ? #73
Motivated by the VirtualGL issue above, I tested Android version of Chrome 54.0.2840.85 which renders websites fine whereas later versions either crash the application window, incorrectly place clickable elements etc.
I downloaded Chrome 54.0.2840.85 from (somewhat untrustful) ApkMirror.com.
Edit:
As I feel it's important to share as much information as possible, I give the following links for any future reference:
GitHub: aosp-mirror/platform_external_qemu - android-emugl (thanks @Niek)
Chrome source: 54.0.2840.85 (app works)
Chrome source: 55.0.2883.32 (app doesn't work)
Niek
commented
3 years ago Thanks a lot for the research @Fincer! Great job on finding a working Chrome version. The diff between the 2 releases is here: https://github.com/chromium/chromium/compare/54.0.2840.85...55.0.2883.32 - that's a lot of changes to go through 😳
What I've tried so far is:
ro.opengles.version property to either 65536 (GLESv1), 131072 (GLESv2) or 196608 (GLESv3) - no effectro.kernel.qemu.gles=0 - no effectANBOX_EGL_LIB variable to something else than libEGL.so - anbox segfaultsNiek
commented
3 years ago There's an interesting PR here: https://github.com/anbox/anbox/pull/1678
Unfortunately it doesn't seem to help in my case (or I'm missing something).
Fincer
commented
3 years ago @Niek
Good finding. Thank you for the link. Unless you already tried, I'll rebuild a new Android image with the PR applied.
Edit: Yeah, you are right. Doesn't work - even with the image rebuilt.
Niek
commented
3 years ago I haven't tried that yet, maybe that helps. Thanks!
Edit: thanks for testing @Fincer!
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
kuailexs
commented
3 years ago try to this PR : https://github.com/anbox/anbox/pull/1875
Fincer
commented
3 years ago @kuailexs
Thank you for your PR! Have you directly tested Chromium browsers or variants?
I applied the PR and did a quick test. Webview Shell works as intended but still no luck with Chromium browsers. Can anyone reproduce?
kuailexs
commented
3 years ago @Fincer I haven't tested Chromium browsers，only Webview Shell.
kuailexs
commented
3 years ago Sorry, my local workspace is not clean and there is something wrong with the submitted code
kuailexs
commented
3 years ago try to this PR: https://github.com/anbox/anbox/pull/1877 update anbox Binary file and android.img Chromium and Webview Shell works tested this apk : https://github.com/bromite/chromium/releases/download/86.0.4240.92/chr_x86_ChromePublic.apk
Fincer
commented
3 years ago @kuailexs Will do later, soon. I'll let you know. Thanks a lot!
kuailexs
commented
3 years ago @Fincer Excuse me, what is the result?
Fincer
commented
3 years ago @kuailexs
Ah, sorry. I've been quite busy with other things.
I just tested the new patch. Compiled both android.img & the anbox software with the patch applied. Still no luck.
Just some minor things: I see your screenshots have output text EGL_RENDERABLE_TYPE can not > EGL_OPENGL_ES2_BIT ... but it seems you have exluded this specific diff from your latest commit:
--- a/src/anbox/graphics/emugl/RendererConfig.cpp
+++ b/src/anbox/graphics/emugl/RendererConfig.cpp
@@ -142,6 +142,13 @@ int RendererConfigList::chooseConfig(const EGLint* attribs, EGLint* configs,
mustReplaceSurfaceType = true;
}
}
+ // EGL_RENDERABLE_TYPE , fix webview
+ if (attribs[numAttribs] == EGL_RENDERABLE_TYPE) {
+ if (attribs[numAttribs + 1] > EGL_OPENGL_ES2_BIT) {
+ ERROR("EGL_RENDERABLE_TYPE can not > EGL_OPENGL_ES2_BIT");
+ return 0;
+ }
+ }
numAttribs += 2;
}Not sure if this is relevant, though.
Moreover, about my setup: I checked I did not use any other conflicting patches or OpenGL settings for anbox that could have altered the testing.
kuailexs
commented
3 years ago Here is a useful but not the best way to modify it，I think we should change 'RendererConfigList::chooseConfig' only,But the tests didn't work。 only change ‘eglGetConfigAttrib’，It worked in my tests， To achieve the same effect
baptx
commented
2 years ago It would be useful to have Chrome and Chromium working on Anbox because there are some things I was not able to dot with Firefox on Android. For example some apps are using a web view to log in and then redirect you to the mobile app with their own URL scheme, which did not work with Firefox. Also I was not able to add a custom CA certificate to the latest Firefox on Android which does not use the CA certificates present on the system unlike Chrome / Chromium. I followed the instructions from https://blog.jeroenhd.nl/article/firefox-for-android-using-a-custom-certificate-authority but I still cannot view the HTTPS traffic in a tool like mitmproxy for websites using HSTS. If someone wants to try Chromium, which is currently not working on Anbox, the official daily build can be downloaded with an app like https://f-droid.org/en/packages/com.anddevw.getchromium/ or directly by getting the APK like the app is doing by first getting the latest build number at https://commondatastorage.googleapis.com/chromium-browser-snapshots/Android/LAST_CHANGE, then use this number in a URL like https://commondatastorage.googleapis.com/chromium-browser-snapshots/Android/932368/chrome-android.zip, unzip the file and install ChromePublic.apk.
Update: I tested the latest Chromium build 932368 with Android x86 on VirtualBox but it crashes also, unlike Chrome. Maybe because this latest build is not stable enough. I also tested the Chromium developer build used in the stable release of Google Chrome, which is currently 911475 according to the instructions from https://www.chromium.org/getting-involved/download-chromium but it did not work either with Android x86 on VirtualBox.
Fuseteam
commented
2 years ago um @baptx doesn't chrome and chromium just work on linux anyway?
baptx
commented
2 years ago @Fuseteam Yes but I need Chrome or Chromium working on Android for the reasons I described because some mobile apps are opening a mobile web browser for authentication with a redirect using their own URL scheme to be logged in on the mobile app.
Fuseteam
commented
2 years ago ah, i didn't think of that thanks for the insight
stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Fuseteam
commented
2 years ago Hmm this still seems relevant
Manouchehri
commented
2 years ago Agreed.
Did anyone manage to get Chrome or Chromium or any derivative working in Anbox? I have tried:
All of them have the same issue: the browser starts fine, but when I try to load any page (or even chrome://version) it hangs. This is the output from
adb logcat:I have tried:
enable-gpu-rasterization- no effectsetprop qemu.gles 0- no effectAny other suggestions?