test: fix tests for lower API levels

[matthiasemde]

Story

This PR fixes issues for instrumented tests with lower API versions or disables them if no fix is available.

Disabling test

For disabling tests, we use the @SdkSupress decorator.

Fixing test

Fixing test is a bit more difficult since many of the errors in the CI did not occur locally.
In an attempt to reproduce the CI environment on my machine and fix the tests, I migrated our test execution to gradle managed devices (god), introduced the AndroidX Test Orchestrator and built a screenshot on test failure feature which helps identify.

Gradle managed devices (gmd)

Using gradle managed devices, we can configure emulators inside our build.gradle.kts file which can then be used for testing. Both in the CI as well as locally. This improves reproducibility of CI test failures.

managedDevices {
  localDevices {
      create("api29") {
          device = "Pixel 6a"
          apiLevel = 29
          systemImageSource = "aosp"
      }
      ...
      create("api35") {
          device = "Pixel 6a"
          apiLevel = 35
          systemImageSource = "aosp-atd"
      }
  }
}

If you want to use these devices for testing, you can use the automatically generated gradle tasks:
$ ./gradlew app:api29DebugAndroidTest

If you want to run only a specific test(-class) you can parameterize the call like this:
$ ./gradlew app:api29DebugAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=app.musikus.library.presentation.LibraryScreenTest#addFolderOrItem_hintDisappears

AndroidX Test Orchestrator

The Android Test Orchestrator improves test stability by running each test in an independent instance of the application.

Screenshot on test failure

Findings and learnings

While fixing the insertItems_checkSorting() test in LibraryFolderDetailsScreenTest I stumbled upon a nasty race condition involving FakeTimeProvider.advanceTimeBy(). When you i.e. create an object in the UI using the ComposeRule and advance the time right afterwards, the timestamp stored in the object can be either the old or the new timestamp depending on how fast the asynchronous execution of the object creation is running. This can result in multiple objects getting the same timestamp even though there is a call to FakeTimeProvider.advanceTimeBy() in-between them.

Helpful links

• https://medium.com/stepstone-tech/how-to-capture-screenshots-for-failed-ui-tests-9927eea6e1e4
• https://medium.com/stepstone-tech/android-test-orchestrator-unmasked-83b8879928fa
• https://developer.android.com/training/testing/instrumented-tests/androidx-test-libraries/runner?source=post_page-----83b8879928fa--------------------------------#using-android-test-orchestrator

[matthiasemde]

https://developer.android.com/training/testing/instrumented-tests/stability

The base branch was changed.