[REQUIRED] Step 1: Describe your environment
- Unity version: 6000.3.11f1
- Google Mobile Ads Unity plugin version: v11.0.0
- Plugin installation method: .unitypackage import (Please change to "Unity package manager" if applicable)
- Platform: Android
- Platform OS version: Android 9 (SDK 28)
- Any specific devices issue occurs on: Tecno CAMON i 4 (and likely other devices running older versions of
chromium-Monochrome)
- Mediation ad networks used, and their versions: None (Please update this if you are using AppLovin, Meta, etc.)
[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
We are experiencing a severe Application Not Responding (ANR) issue in our production build. The ANR is caused by the main UI thread getting permanently deadlocked while the Google Mobile Ads SDK attempts to draw a WebView component.
The stack trace indicates that com.google.android.gms.ads.internal.webview.ai.onDraw drops into obfuscated native Chromium code (J.N.ZIIIIIIJOZZ) and gets stuck indefinitely waiting for a lock (art::ConditionVariable::WaitHoldingLocks).
Because this appears to be a low-level synchronization issue within the device's specific System WebView version, it is difficult to reproduce reliably on demand. It occurs in the production environment during standard ad initialization and display workflows:
- Initialize the Google Mobile Ads SDK.
- Request and attempt to display an ad.
- The main thread freezes during the WebView's
onDraw pass, eventually triggering the system ANR dialogue (intercepted by Signal Catcher in the logs).
Relevant Stack Trace (main thread):
"main" tid=1 Native
#00 pc 0x0000000000019d1c /system/lib/libc.so (syscall+28)
#01 pc 0x00000000000a6b63 /system/lib/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+78)
#02 pc 0x00000000003d493f /system/lib/libart.so (art::GoToRunnable(art::Thread*) (.llvm.4286800627)+314)
#03 pc 0x00000000003d47dd /system/lib/libart.so (art::JniMethodEnd(unsigned int, art::Thread*)+8)
at J.N.ZIIIIIIJOZZ (Native method)
at HN.g (chromium-Monochrome.aab-stable-720417920:288)
at HN.onDraw (chromium-Monochrome.aab-stable-720417920:7)
at com.android.webview.chromium.WebViewChromium.onDraw (chromium-Monochrome.aab-stable-720417920:31)
at android.webkit.WebView.onDraw (WebView.java:3097)
at com.google.android.gms.ads.internal.webview.ai.onDraw (:com.google.android.gms.policy_ads_fdr_dynamite@260480608@260480602017.868869642.868869642:8)
at android.view.View.draw (View.java:20838)
at android.view.View.updateDisplayListIfDirty (View.java:19678)
at android.view.View.draw (View.java:20551)
at android.view.ViewGroup.drawChild (ViewGroup.java:4425)
at android.view.ViewGroup.dispatchDraw (ViewGroup.java:4204)
Relevant Code:
C#
// The issue occurs under the hood during standard ad rendering.
// No custom threading is used; all MobileAds initialization and loading calls
// are made directly on the Unity Main Thread.
MobileAds.Initialize((InitializationStatus initStatus) => {
// Initialization callbacks
});
// Happens during standard ad rendering/display loops.
[REQUIRED] Step 1: Describe your environment
chromium-Monochrome)[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
We are experiencing a severe Application Not Responding (ANR) issue in our production build. The ANR is caused by the main UI thread getting permanently deadlocked while the Google Mobile Ads SDK attempts to draw a WebView component.
The stack trace indicates that
com.google.android.gms.ads.internal.webview.ai.onDrawdrops into obfuscated native Chromium code (J.N.ZIIIIIIJOZZ) and gets stuck indefinitely waiting for a lock (art::ConditionVariable::WaitHoldingLocks).Because this appears to be a low-level synchronization issue within the device's specific System WebView version, it is difficult to reproduce reliably on demand. It occurs in the production environment during standard ad initialization and display workflows:
onDrawpass, eventually triggering the system ANR dialogue (intercepted bySignal Catcherin the logs).Relevant Stack Trace (
mainthread):Relevant Code: