If it's always an APK in /system/app then this indicates the user hasn't updated WebView ever and is using the built-in version, which will be very old on an M device like the one you quoted here. Probably whatever bug is being hit is already fixed in newer WebView versions and users should update, and even if it's not already fixed, users who don't update wouldn't get any fix we implemented if they never update :|

I assume you're reporting this based on the information you see in the Play Store crash dashboard for your app? Unfortunately the information you see there and copied here is not really enough to diagnose issues - we need the full microdump printed into the system log at the time of the crash, and there's no way for you to get that from the dashboard.

If you can link us to your application's page on the Play Store (or just give us the full package name), we can look in our own crash backend to see what issues your app is having across which webview versions, and hopefully identify the issue for you so that we can fix it or confirm that it's definitely already fixed in a later version.

Sorry for the inconvenience here; if you can give us that information we'll try our best to help you resolve this!

Thanks for the update. Yes, I am looking at the play store console for the said backtrace.

The full package name for my app is "to.go".

Let me know if you need anything else.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ah, yes, I see that in the debuggerd output now - I didn't twig that was actually the package name, good short domain ;)

So for your app there's a couple of things I see:

1) there's people on webview 60 who are seeing a crash in cc::SingleThreadProxy::DidLoseCompositorFrameSinkOnImplThread, but this hasn't happened on any later version (the current stable version is 65) so this is probably already fixed.

2) there's at least one case where your app is throwing an uncaught exception in a WebView callback, causing WebView to crash - you should make sure you don't let exceptions "escape" from any of the WebView callback functions, since this usually causes a hard-to-interpret native crash (we're working on improving this so that you'll see the Java exception more clearly in the dashboard):

java.util.ConcurrentModificationException
at java.util.ArrayList$ArrayListIterator.next	(ArrayList.java:573 )
at to.go.app.customFields.UICustomFieldsProvider.getOrderedCustomField	(UICustomFieldsProvider.java:53 )
at to.go.ui.search.SearchItemsProvider.getSearchContactItem	(SearchItemsProvider.java:582 )
at to.go.ui.search.SearchItemsProvider.getSearchItem	(SearchItemsProvider.java:507 )
at to.go.ui.search.SearchItemsProvider.getSortedSearchItems	(SearchItemsProvider.java:495 )
at to.go.ui.search.SearchItemsProvider.getFrequentChatItems	(SearchItemsProvider.java:277 )
at to.go.ui.search.SearchItemsProvider.getTopSearchedItems	(SearchItemsProvider.java:150 )
at to.go.ui.integrations.searchCallback.SearchCallbackHandler.getSearchResponseString	(SearchCallbackHandler.java:79 )
at to.go.ui.integrations.searchCallback.SearchCallbackHandler.getCallbackResponseString	(SearchCallbackHandler.java:59 )
at to.go.ui.integrations.searchCallback.SearchCallbackHandler.handleSearch	(SearchCallbackHandler.java:204 )
at to.go.ui.integrations.IntegrationWebviewFragment.handleIntegrationCallback	(IntegrationWebviewFragment.java:280 )
at to.go.ui.integrations.IntegrationWebviewFragment.access$100	(IntegrationWebviewFragment.java:59 )
at to.go.ui.integrations.IntegrationWebviewFragment$1.shouldOverrideUrlLoading	(IntegrationWebviewFragment.java:157 )
at com.android.webview.chromium.WebViewContentsClientAdapter.shouldOverrideUrlLoading	(WebViewContentsClientAdapter.java:76 )
at org.chromium.android_webview.AwContentsClient.shouldIgnoreNavigation	(AwContentsClient.java:15 )
at org.chromium.android_webview.AwContentsClientBridge.shouldOverrideUrlLoading	(AwContentsClientBridge.java:160 )
at org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce	(Native Method )
at org.chromium.base.SystemMessageHandler.handleMessage	(SystemMessageHandler.java:9 )
at android.os.Handler.dispatchMessage	(Handler.java:102 )
at android.os.Looper.loop	(Looper.java:148 )
at android.app.ActivityThread.main	(ActivityThread.java:5451 )
at java.lang.reflect.Method.invoke	(Native Method )
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run	(ZygoteInit.java:726 )
at com.android.internal.os.ZygoteInit.main	(ZygoteInit.java:616 )

3) there's a number of crashes where we aren't getting a complete/valid crash dump and so can't tell what is actually happening. This is happening only for users with very old WebView versions like 51, and is probably the case the report you quoted here falls into, unfortunately. There's not a lot we can do about this if users don't update :(



So, unfortunately I don't think there's anything in particular we can help you with here at the moment, sorry. I'm going to close the bug for now.

This issue has reminded me that the information surfaced in the Play Store dashboard for developers is still often unhelpful for WebView crashes, and I've added a task to our work queue to look into improving this, hopefully in the near future.

Thanks for the analysis. Should we ask our users to update both of Chrome and Android System Webview?

For 2), is it possible to know the number of instances?. The crashes have started increasing only in the last 60 days. So, we wanted to ensure we have all the possible causes underlined.

There was only one instance of that Java exception crash in the db.

You could suggest that your users update WebView - they should be doing that anyway as it's critical to many applications. If you want to detect it inside the app and prompt users, you need to be careful how you do this, since the correct thing to update is different on different devices (pre-N devices need to update WebView, N+ devices may need to update either chrome or webview depending how the user has configured that device).

There's an example of how to detect the webview version and send the user to the correct play store page here: https://github.com/ntfschr-chromium/ct_workaround - this was written for a specific bug with Symantec certificates back in an older version of WebView so the version range it's trying to detect isn't relevant to you, but the code to retrieve the version and to send the user to the correct play store page is useful for any issue.