* For #11664 — Fixup MissingResourceExceptions being thrown in exotic Locales (#13124)
Our kotlin code is not catching the `MissingResourceException` in the `LeanplumMetricsService` which results in the app crashing when the locale isn't known by the device.
Catches the exception, and falls back to the ISO 639 language code. This isn't a great solution, because ISO 639 isn't especially stable.
In practice however this is almost certainly never going to be a problem because Leanplum isn't going to be supported in such exotic locales.
In this case, using the ISO 639 language code allows the error message to be more informative.
* Bump AC version to uplift pairing crash AC#7944
Co-authored-by: jhugman <jhugman@users.noreply.github.com>
Our kotlin code is not catching the `MissingResourceException` in the `LeanplumMetricsService` which results in the app crashing when the locale isn't known by the device.
Catches the exception, and falls back to the ISO 639 language code. This isn't a great solution, because ISO 639 isn't especially stable.
In practice however this is almost certainly never going to be a problem because Leanplum isn't going to be supported in such exotic locales.
In this case, using the ISO 639 language code allows the error message to be more informative.
Co-authored-by: jhugman <jhugman@users.noreply.github.com>
Stricter synchronization by always using the same "loadedSearchEngines"
variable.
With "loadedSearchEngines" calling "refreshAsync()" we also get the fallback
engines to contain reddit and youtube (which are programatically added) and
also now we properly remember and display the engines added by user.
We have two search engine types:
- one based on MLS reported region,
- one based only on Locale.
There are multiple steps involved in returning the default search engine for
example and though at each step we could verify if a certain operation is
completed we are still exposed to concurrency issues.
Simplest and most effective way to make sure the MLS engines do not mix with
Locale based engines is to use the same type of engines for the entire duration
of the app. At the next cold start we'll verify again which engines to use.
Using the Locale based engines (fallbacks) is expected to only happen once, at
the first run of the application after being installed.
This is functionally equivalent to the code before this patch but should
be slightly more performant in theory because ConstraintLayout is
expensive to inflate.
The elevation and layoutParams set dynamically appeared to have no effect
with the wrapping view but broke the view when used by itself so I had
to remove them. I also updated a few other unnecessary params.
Theoretically this may have some perf benefits but I didn't see anything
outside noise levels after I took the numbers (but I didn't try very
hard).
* for #11830 added new metric for collecting startup method
move all source startup telemetry into its own logic and added an UNKOWN state
* switched back to onNewIntent solution
* renamed the metric