Fix calls on Huawei devices: skip addWebMessageListener on Chromium < 119

[manfrommedan]

Problem

Calls do not work on Huawei and other devices with system WebView based on Chromium < 119. The call screen shows "Join as guest" instead of the call UI.

Huawei WebView reports WEB_MESSAGE_LISTENER as supported via WebViewFeature.isFeatureSupported(), but silently drops messages sent through addWebMessageListener. This is a known issue across the Android ecosystem. Capacitor, Home Assistant, Flutter InAppWebView and Tauri have all documented workarounds for Huawei WebView (see ionic-team/capacitor#6555, ionic-team/capacitor#6258).

Huawei does not allow users to change the WebView provider on their devices.

Fix

• Register addJavascriptInterface unconditionally as the baseline message channel (works on all WebView implementations)
• Only use addWebMessageListener when the WebView is based on Chromium 119+, where it is known to work reliably
• On Chrome 119+ both are registered, addWebMessageListener takes priority (same behavior as before)
• On Chromium < 119 only addJavascriptInterface is used, avoiding the broken addWebMessageListener

Note

There is a second issue affecting these devices: Element Call JS bundle uses Promise.withResolvers (Chrome 119+), which causes the ES module to silently fail on older WebViews. A polyfill fix for that has been submitted to Element Call: element-hq/element-call#3905

Test plan

• Tested on Huawei device with WebView Chromium 114: calls work correctly
• Built from source, full debug APK verified on device
• compileDebugKotlin passes, full assembleDebug passes

Related: #6632

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

[CLAassistant]

All committers have signed the CLA.

[manfrommedan]

I have read the CLA Document and I hereby sign the CLA

[jmartinesp]

Thanks, the feature still works well in a device not affected by the issue. It would be nice to double check with some other affected user if this fixes their problems, but I guess the EC PR needs to be merged and integrated first.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.24%. Comparing base (24b24e5) to head (8ae835e).
⚠️ Report is 97 commits behind head on develop.

Files with missing lines	Patch %	Lines
...call/impl/utils/WebViewWidgetMessageInterceptor.kt	0.00%	10 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #6640      +/-   ##
===========================================
+ Coverage    81.18%   81.24%   +0.05%     
===========================================
  Files         2626     2626              
  Lines        73165    76940    +3775     
  Branches      9487     9493       +6     
===========================================
+ Hits         59400    62509    +3109     
- Misses       10281    10948     +667     
+ Partials      3484     3483       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maksimkurb]

Can confirm that applying this fix as well as element-hq/element-call#3905 fix problems with calling on Huawei devices (tested at least on two different phones). Thanks a lot!

[bestperson-free]

Подтверждаю, что применение этого исправления, а также решения проблемы element-hq/element-call#3905, устраняет проблемы со звонками на устройствах Huawei (проверено как минимум на двух разных телефонах). Большое спасибо!

Какую версию сейчас можно использовать?

[maksimkurb]

Какую версию сейчас можно использовать?

Until these two fixes are merged into the main branch you can clone repositories and compile them manually: firstly, patch element-call and publish it to the local maven repository under some version like 0.19.999-SNAPSHOT to avoid collisions with real versions, then patch element-x-android with this fix and replace element-call version from 0.19.x to 0.19.999-SNAPSHOT. Also, you would need to add mavenLocal() to the repositores section in the build.gradle files.

I can share my built APKs with you, but use them at your own risk: I am just a stranger from the Internet, and you don't have to trust my APKs as they can contain backdoors and etc (I'm not a bad guy, I just tell you to be cautious). Ideally, you can use these APKs on some non-production matrix server with two demo accounts just to test that this fix works and then compile Element X by yourself or wait until this fix will be merged and released.

[jmartinesp]

Approving this since I could confirm the 'normal' scenario works as expected and some affected users have confirmed this fixes the issue for them when applied with another fix in the Element Call side.

[dreamzxb]

After testing Element X for Android v26.05.0, it appears this issue has not yet been resolved; the problem persists on Android devices exactly as it did before.

[maksimkurb]

MR on the element-call side has not been merged yet, and it is also required to fix calls on Huawei.
You should wait until element-hq/element-call#3905 is merged and then wait until element-x-android updates its element-call dependency to the fixed version.