The StartupActivityStateProvider uses an imperative implementation,
driven by callbacks, to set the state of the application. This is hard
to follow as you need to understand which callbacks will be called in
which order. For example, to make sense of an implementation like this,
COLD, WARM, AND HOT would likely need to be implemented in separate
ActivityLifecycleCallbacks.
I feel the StartupStateProvider is an improvement because it leverages
the StartupActivityLog to query a linear state for a more understandable
implementation. Furthermore, it seems accessible to write COLD, WARM,
and HOT in the same class because they can all be approached the same
way.
* Add intent processor for locale changes
* Recreate notification and notify in the service
* Use locale use cases to update notification
* Use notification id instead of tag
* Add locale use cases and restore locale in application
* Send locale to service instead of string
* Controller tests for locale
* Update Android Components version to 74.0.20210323143308
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
(cherry picked from commit 559cf54798)
* Add intent processor for locale changes
* Recreate notification and notify in the service
* Use locale use cases to update notification
* Use notification id instead of tag
* Add locale use cases and restore locale in application
* Send locale to service instead of string
* Controller tests for locale
* Update Android Components version to 74.0.20210323143308
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
Hopefully this will help us understand behavior of the
`application_on_create` probe, specifically that it seems to take longer
in telemetry than in does locally compared to `home_activity_on_create`
(comparing the medians to local runs)..
Only on API 23+ (minimum Android version needed for SecureAbove22Preferences)
and only if enabled by a Nimbus experiment.
The Nimbus experiment will have the key `fenix-android-keystore` and use the
default branches - "control" and "treatment".
Only on API 23+ (minimum Android version needed for SecureAbove22Preferences)
and only if enabled by a Nimbus experiment.
The Nimbus experiment will have the key `fenix-android-keystore` and use the
default branches - "control" and "treatment".
Previously setting it might have been arbitrarily delayed, resulting in
this metrics missing from pings that get submitted earlier.
Setting it early should prevent that.
The performance impact is negligible, Glean dispatches recording that
data off-main-thread anyway.
I validated:
- that the log statement appeared in Nightly but not in Beta.
- that the local runtimes of our perftest increased (the median diff is 124ms)
* For #15278: added CoroutineManager to count runBlocking calls
* For #15278: Added actual detekt rule for runblocking and its config to the yaml
* For #15278: Added unit test for RunblockingCounter
* For #15278: renamed StrictModeStartupSuppressionCountTest.kt to PerformanceStartupTest.kt and added runBlockingCount test
* Lint fix
* For #15278: made runblocking a Long to prevent overflow
* For #15278: fixed MozRunblocking name, description and moved RunBlockingCounter to perf package
* For #15278:Renamed MozillaRunblockingCheck to MozillaRunBlockingCheck
* For #15278: Added setup for unit test, since it failed without restting counter
* For #15278: Fixed naming for RunBlocking lint check
* For #15278: removed changes made to test to use runBlockingIncrement
* For #15728: added test exclusion for runBlocking check
* For #15278: changed null check and added Synchronized to count setter
* For #15278: fix for nits
* For #15278: added StartupExcessiveResourceUseTest to CODEOWNERS
* For #15278: fixed for nits
* For #15278: Moved increment function to extension function and fixed indentation
* For #15278: Added tests for Atomic Integer extension and nit fix
* For #15929: Remove SearchWidgetCFR telemetry.
* For #15929: Remove SearchWidgetCFR and search widget experiment.
* For #15929: Remove unit tests references to search widget experiment.