Handle failures to parse system WebView version

[lukstbit]

Purpose / Description

There are several reports in acra about crashes in checkWebviewVersion() when parsing the system WebView version. It seems some of those versions appear as "Developer Build" and not a simple number like we expect.

https://ankidroid.org/acra/app/1/bug/256775/report/e8bb99dc-2cb8-4a73-ab66-3491c1e2752f
https://ankidroid.org/acra/app/1/bug/253230/report/6d761065-e7d6-498a-9323-84a68f7fbfd4

Stacktrace:

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.ichi2.anki/com.ichi2.anki.DeckPicker}: java.lang.NumberFormatException: For input string: "Developer Build"
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2683)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2744)
	at android.app.ActivityThread.-wrap12(ActivityThread.java)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1495)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:154)
	at android.app.ActivityThread.main(ActivityThread.java:6181)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:893)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:783)
Caused by: java.lang.NumberFormatException: For input string: "Developer Build"
	at java.lang.Integer.parseInt(Integer.java:521)
	at java.lang.Integer.parseInt(Integer.java:556)
	at com.ichi2.anki.InitialActivity.checkWebviewVersion(InitialActivity.java:147)
	at com.ichi2.anki.DeckPicker.onCreate(DeckPicker.kt:573)
	at android.app.Activity.performCreate(Activity.java:6785)

The fix consists in catching exceptions from version parsing and displaying a dialog about the minimum WebView version. I also added a checkbox to this dialog to hide the dialog on future runs, if the users have a developer build it seems reasonable to expect it's above our minimum WebView version requirements.

The dialog:

I added the Review High Priority label because I think these users can't access the DeckPicker.

How Has This Been Tested?

Not tested, just opened the dialog to see how it looks.

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[github-actions]

Important

Maintainers: This PR contains Strings changes

1. Sync Translations before merging this PR and wait for the action to complete
2. Review and merge the auto-generated PR in order to sync all user-submitted translations
3. Sync Translations again and merge the PR so the huge automated string changes caused by merging this PR are by themselves and easy to review

[mikehardy]

I was tempted to say "this was mostly for developers using really old emulators that can't update so just let it pass if we can't parse it" but then I saw that one of them was actually out of date - our minimum is 77 and this was M74:

App_Chromium_M74_for_AFP_dvlp_20191128_1

Which is kind of crazy.

So I think experimentation with Brayan's suggestion is really worthwhile - we can likely not crash and only allow webviews that are actually new enough

There's a compat API that allows us to use longVersionCode for all APIs

https://developer.android.com/reference/kotlin/androidx/core/content/pm/PackageInfoCompat?hl=en#getLongVersionCode(android.content.pm.PackageInfo)

As an incremental improvement - that may be sufficient without any ability to suppress+continue so could be cherry-picked easily if it was in one nice commit

As a feature, the ability to suppress + continue seems nice but strings are hard to cherry-pick across branches so that would be better as a 2.20 commit and it would need to be separate

[lukstbit]

I switched to using the compat longVersionCode that Brayan suggested. Hope the version code I found is ok, see commit message.
I've also not made any changes to strings to not mess cherry-picking and left a TODO for that for now.

[BrayanDSO]

AFAICT, the webview version code is alright. It looks like it follows a pattern and starts with the third element in the version name.

e.g. 119.0.6045.193 → 604519326