unity-webview

The Android implementation requires specific configurations depending on the features you use.

File Input Fields

If you need file input fields, ensure you have android.permission.READ_EXTERNAL_STORAGE, android.permission.WRITE_EXTERNAL_STORAGE, and android.permission.CAMERA permissions. If you do not need file input fields, use dist/unity-webview-nofragment.unitypackage to avoid using Android Fragments.

Camera and Microphone Access

To enable camera or microphone access via navigator.mediaDevices.getUserMedia, you must define specific script constants and call the corresponding runtime methods:

1. Camera:
   • Define UNITYWEBVIEW_ANDROID_ENABLE_CAMERA.
   • Call webViewObject.SetCameraAccess(true); at runtime.
2. Microphone:
   • Define UNITYWEBVIEW_ANDROID_ENABLE_MICROPHONE.
   • Call webViewObject.SetMicrophoneAccess(true); at runtime.

Note: For Android API 23+, you must also request these permissions at runtime using UnityEngine.Android.Permission.

When using the Windows Editor or Standalone builds, loading heavy websites (e.g., those with extensive JS or hash-based navigation like https://www.interserv.com.tw/#service) can cause Unity to crash during the Destroy process. This is typically due to a race condition between the main thread and the STA thread when WebView2 is in a 'busy' or 'loading' state.

To mitigate this, implement the following two core fixes:

1. Stop navigation before releasing COM (C++)

In plugins/Windows/WebViewPlugin.cpp, within the WM_WEBVIEW_DESTROY case, ensure you call Stop() on the webview instance before setting the controllers to nullptr. This allows WebView2 to cancel ongoing navigation and exit the busy state before the COM objects are released.

2. Prevent race conditions in C# OnDestroy

In the C# implementation (e.g., plugins/WebViewObject.cs), modify the OnDestroy logic for Windows platforms. You must nullify the webView pointer before calling the native destroy method. This prevents the Update loop from attempting to call GetMessage or Render on a pointer that is currently being destroyed in the native layer.

Recommended Implementation Pattern:

if (webView == IntPtr.Zero) return;
var ptr = webView;
webView = IntPtr.Zero;
_CWebViewPlugin_Destroy(ptr);

When using unity-webview on Windows, the visual content is rendered via CapturePreview off-screen bitmaps. To prevent the Unity texture from getting stuck on old frames or failing to update during rapid navigation, follow these integration patterns:

Prevent Texture Freezing

If the WebView texture stops updating, it is often because the captureInProgress flag is stuck. Ensure that navigation completion events are correctly clearing this flag so that the next Unity Update cycle can schedule a new CapturePreview request.

Handle Rapid URL Switching

To avoid race conditions where a new Navigate call is ignored because a previous navigation hasn't finished stopping, implement a delayed navigation pattern:

1. Stop the current navigation.
2. Clear the capture/refresh flags.
3. Delay the new Navigate call to the next message loop (e.g., using PostMessage instead of immediate execution).

Configure Refresh Rate

On Windows, the WebViewObject uses a bitmapRefreshCycle to control how often the off-screen texture is captured.

• Default value: 10 (recommended for performance).
• High-frequency updates: If the visual updates feel sluggish, you can manually lower this value (e.g., to 3) to increase the redraw frequency, though this will increase CPU/GPU usage.