Hi @Marinofull thanks for this PR.

A few months ago we had Guava auto-updated to 32.x (#8547), and the problem was that it forced projects that use Robolectric to update to at least Gradle 7.x.

See:
google/guava#6612
google/guava#6801

@hoisie thanks. But Robolectric master version uses gradle 8 now, correct?

I see now, it will force not only Robolectric, but any project using it to upgrade. And since the latest version of agp compatible with gradle is agp 7.4.2 any project using it will also be vulnerable to this same issue, not because of guava only, but because of its other dependencies such as agp 7.4.2. In this case, I think we can close this PR, and upgrade when agp 7 became deprecated

What do you think @utzcoz? Maybe we should just go along with the rest of the ecosystem which has probably already upgraded past Gradle 6?

Maybe we should just go along with the rest of the ecosystem which has probably already upgraded past Gradle 6?

At least, I know there is a large user that can't use AGP 7.x.

At least, I know there is a large user that can't use AGP 7.x.

@utzcoz do you have some insights about why they can't update AGP/Gradle?

According the Gradle's Release end-of-life Policy, Gradle 8.x is the currently supported version, Gradle 7.x only receives critical bugfixes, and older versions are no longer supported.
As Gradle 8.0 has been released in February 2023, over one year ago, maybe it could make sense to reconsider this (depending on the blockers provided above)?