This should prevent issues with the cleanup being done earlier (even in @After)
and affecting the behavior of the Activity which is still running.
With this issue fixed I've re-enabled verifyCustomizeHomepageTest.
Because when FeatureSettingsHelper is instantiated it caches the settings
values from that instant it's important to only use one instance of it so I've
updated all tests that are using HomeActivityTestRule.
HomeActivityIntentTestRule may be updated with a similar functionality later.
* For #26792 - Change active Firebase Test Lab emulator from x86 to ARM
Update startup-test kind.yml Jobs for ARM
Update ui-test kind.yml Jobs for ARM
Cleans up and renames Flank configurations for ARM
Updates ui-test.sh for ARM
* Fix BookmarksTest.kt and HomeScreenTest.kt
* Fix intent matcher for SettingsAboutTest
Adds a helper function for Play Store intent
* Fix SettingsSearchTest.kt
* ktlint fix TestHelper.kt and SettingsRobot.kt
Unify the TCP feature with the TCP setting allowing both to be controlled
through the same Nimbus experiment.
Allow changing the default cookie policy to TCP based on the Nimbus experiment.
PRs created by github actions don't get a pull-request taskcluster graph
scheduled (because that is only done for PRs created by collaborators).
However, if the PR is created in the main fenix repo, typically because
it comes from one of our internal github workflows, then we get a push
graph, which is sufficient to run the required checks.
This change lets mergify consider a green `complete-push` task as
sufficient to queue a PR (in addition to all the other conditions, e.g.
wrt review), which will allow PRs created by the
update-nimbus-experiments workflow to be queued by mergify instead of
having to be merged by a repo admin.
Split loading the bitmap from storage and actually setting it in two operations
with one that can run in parallel with onCreateView for HomeFragment and one
that can be used serially on the main thread to actually set the wallpaper.
This seems like the best compromise to ensure that everytime the homescreen is
shown it will have the wallpaper set but does affect the performance - there is
a delay in showing HomeFragment to account for waiting for the wallpaper to be
set.
In testing the new delay seems close to the one from the initial wallpapers
implementation. See more in https://github.com/mozilla-mobile/fenix/pull/26794.