also happens on Nexus 6, MOB30Q, 53.0.2774.2

Logs @ http://go/chrome-androidlogs1/6/624089

/AndroidRuntime( 4187): java.lang.NoClassDefFoundError: android.webkit.ServiceWorkerController
E/AndroidRuntime( 4187): 	at libcore.reflect.InternalNames.getClass(InternalNames.java:55)
E/AndroidRuntime( 4187): 	at java.lang.Class.getDexCacheType(Class.java:476)
E/AndroidRuntime( 4187): 	at java.lang.reflect.ArtField.getType(ArtField.java:94)
E/AndroidRuntime( 4187): 	at java.lang.reflect.Field.getType(Field.java:135)
E/AndroidRuntime( 4187): 	at java.lang.Class.getDeclaredFields(Class.java:909)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.al.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.al.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.al.<init>(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.bh.<init>(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.ag.<init>(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.ah.<init>(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.bm.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.y.b(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.y.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.z.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.u.a(Unknown Source)
E/AndroidRuntime( 4187): 	at com.moat.analytics.mobile.w.run(Unknown Source)
E/AndroidRuntime( 4187): 	at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime( 4187): 	at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime( 4187): 	at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime( 4187): 	at android.app.ActivityThread.main(ActivityThread.java:5258)
E/AndroidRuntime( 4187): 	at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime( 4187): 	at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime( 4187): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
E/AndroidRuntime( 4187): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

ServiceWorkerController is a WebView API that is published in Android N. Seems the app (the analytics library) is trying to access it in a Pre-N device using reflection and crashing. 

 Issue 624896  has been merged into this issue.

 Issue 625119  has been merged into this issue.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/d4020c004324666e1387ed389a30d6929ed5927c

commit d4020c004324666e1387ed389a30d6929ed5927c
Author: Selim Gurun <sgurun@google.com>
Date: Fri Jul 08 21:12:20 2016

Moving this nonessential bug to the next milestone.

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

What is the logic behind the change in Comment #10? Do the apps try to fetch each class that is used in our code?

Yes, that's exactly what they're doing.

I looked into the decompiled code a bit, and I think I've figured out what the point of this code is: they're implementing a getWebViewClient method in what they probably believed was a future-proof way, which is ironically causing a compatibility issue in a way that implementing it in a much simpler and less future-proof way would not :/

It creates a temporary WebView and a temporary WebViewClient, and calls setWebViewClient to associate them. It then searches (breadth-first i think?) through all fields of the WebView class, and all fields of all classes referenced by the WebView class, and so on, until it finds a field which 1) has its value set to the temporary WebViewClient and 2) has a type that's assignable to WebViewClient. It then makes a note of the "path" of field names that leads from the WebView to that field. Having done that, it can then use that path to get the WebViewClient associated with any WebView instance: they've implemented "getWebViewClient".

If they'd just hardcoded the list of fields to use on each Android version, this would probably have been fine: I suspect there's only three versions required (the old webview pre-JB, the old webview on JB where we had inserted the extra abstraction to switch webviews, and the new webview on KK+) since this isn't something we've had much reason to change, and it would remove the need to call getDeclaredFields which is what crashes here.

We should probably add getters for WebViewClient and WebChromeClient (and any other fields we currently only have a setter for) in the next version of Android, just to prevent people needing to do this kind of crazy thing in future.

yeah we need to add an API in the next version. 
Torne's explanation is pretty much correct. They tried to solve it such that it would continue to work even when we change webview internal names but then failed when new types that did not exist in previous SDK are added.

[Automated comment] Less than 2 weeks to go before stable on M52, manual review required.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Merge approved for M52 branch 2743.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/d868d58a78ed85eb5b2ea2cdf76ea945bd1fb6c7

commit d868d58a78ed85eb5b2ea2cdf76ea945bd1fb6c7
Author: Selim Gurun <sgurun@google.com>
Date: Fri Jul 08 21:12:20 2016

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/358d8e548ffa82be9e25137c0573d785c288263d

commit 358d8e548ffa82be9e25137c0573d785c288263d
Author: Selim Gurun <sgurun@google.com>
Date: Fri Jul 08 21:12:20 2016

 Issue 627551  has been merged into this issue.

Fix verified, crash no longer reproducible, tested on Dell Venue 10 7040/LMY47I, Webview: 52.0.2743.79 & 53.0.2785.20