Bump androidx.appcompat:appcompat from 1.5.1 to 1.6.1

[dependabot]

Bumps androidx.appcompat:appcompat from 1.5.1 to 1.6.1.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

> **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[abelgardep]

@dependabot rebase

[jesmrec]

@dependabot rebase

[Aitorbp]

Summary:

Too many test flakies when appcompat version is upgraded. The following scenarios have been tried to try to find a correct solution but it has not worked:

Putting delays:

I have tried putting delays in the tests to see the behavior. Based on the fact that it is not a good practice, the result has been negative, there were cases in which the tests were not even passed locally.

Create a rule in tests:

Since there is a significant number of flakies in each workflow, according to some documents you recommend creating a rule in the tests to re-execute those tests that have failed.
It has been tested locally and the tests pass perfectly but in Bitrise there is no notable improvement.
Create a test rule to repeat a test until it fails locally. I set the test to be repeated 100 times, but none of these iterations failed.
It should be noted that the local tests are not failing, so I understand that there must be a problem with Bitrise, which is where the flakies are appearing.

Bitrise:

An investigation has been done to see if Bitrise is closely related to this increase in flakies. For them the following scenarios have been tested:

1. Increase the version of the Android emulator in Bitrise. It is currently in the NexusLowRes,28,en,portrait. It has been tried to go up to 30, since it is the maximum version that this emulator supports. The result has not been what was expected. Flaky tests have increased considerably.
   It has been tested by changing the emulator to SmallPhone.arm, setting version 32, which is also supported in our project. The result has not been what was expected either. Errors appeared in the tests of these classes. I tried with more device and it is not working neither.

2. Use Orchestrator: According to the Bitrise documentation when you set Use Orchestrator input to true in the Step's Instrumentation Test section. This improves isolation between test cases, making your tests less likely to fail. You can see the benefits and drawbacks of Orchestrator here. But, no improvement has been observed, quite the contrary, the number of tests has increased.

[dependabot]

A newer version of androidx.appcompat:appcompat exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.