* 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
Initially we did this to avoid a duplicated task right after the migration from Fennec. We'd end up
with the original task from Fennec and the new one from Fenix; with the Fennec task still showing
Fennec in the app switcher, but launching Fenix once selected.
Anyhow, now on Android 11 this causes the Fenix task to get duplicated. The simple fix is to not
do any of that anymore. This may re-introduce the problem with the Fennec migration, but:
* We are at 100% rollout for quite some time. There are still users migrating, but the impact
of the bug is much lower.
* The bug after the migration was only temporary. This bug here is happening every time you
launch Fenix. So I'd rather fix this than a possible inconvenience right after the migration.
Reusing the same taskAffinity makes sure that we are launching into a potentially already
existing task from Fennec. Without that we may spawn a new task and will show up twice
in "Recent apps" - with one entry still having a fennec screenshot.
This new event will be sent when the user has successfully migrated from Fennec
to Fenix.
This event will only be sent to Leanplum and not to the other telemetry
services like Glean or Adjust.
Co-authored-by: ValentinTimisica <valentin.timisica@softvision.ro>
In order to ensure that the user's migration screen is not being bypassed by mistake, we handle the
migration's store COMPLETED state the same way we handle the MIGRATING state.
We can do this because we can treat the initial state (NONE) as being either a fresh start of the
app, either the user's intention of starting the home activity.
Before this change, if the app was being open from the shortcut after the migration was complete,
the user would have been encountered the home activity instead of the migration one.
* With this patch fenix build variants will launch HomeActivity directly from the launcher.
This will get rid of the performance regression outlined in #7818.
* Fennec build variants will launch into MigrationDecisionActivity which will show the
migration UI or launch normally into the app. This is faster than going through
IntentReceiverActivity (measured and perceived).
