IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Radha Nakade <radhanakade@google.com>
Link:      https://android-review.googlesource.com/3510337

Migrate traffic from pixel2 to mediumphone on FTL emulators.

Migrate traffic from pixel2 to mediumphone on FTL emulators. 
 
Bug: 396715333 
 
Test: ./gradlew emoji2:emoji2-emojipicker:ftlmediumphoneapi33 
Change-Id: If5555443ca1a91479128e1bd6f4f909154c40ba2

One possibility from a quick look around: org.gradle.api.artifacts.ResolutionStrategy { failOnChangingVersions() } ?

No, we still want it to be able to resolve to a newer version at build time.

In the cases where that is necessary, should we not just import the correct explicit version in the build.gradle files?

We want to depend on the lowest required version. If we're getting a newer one due to transitive dependencies, that's fine, but we don't want to automatically propagate it as an explicit (and potentially unwanted, if transitive dependencies change) upgrade.

Did some digging on what happened here. wear/compose/compose-material/build.gradle depends on the broken version 1.8.0-beta1, but it also depends on project(":wear:compose:compose-foundation"), and that wear/compose/compose-foundation/build.gradle has correct 1.8.0-beta01 dependencies.

Gradle saw the version conflict between the two and picked 1.8.0-beta01 over 1.8.0-beta1.

I think there is something to be said that if your dependency pulls in a newer version than you, then you are in fact forcing devs to that newer dependency. I see Owen's point that for explicit dependencies that get upgraded silently, we should probably force the version to be stated explicitly.

radhanakade@'s WIP work on dependency analysis plugin might help us here as a building block.

I'm not totally on board yet, since a library's own dependency declarations should reflect its own API or implementation dependencies -- not its transitive dependencies which are not under its direct control.

If we do make that a policy, can we do it in a way that avoids forcing a dependency change in a commonly-used library to be accompanied by changes to build.gradle files across a potentially large set of dependent libraries?

Normally, projects will be depending on prebuilt versions of those common libraries, so for those changes there will be no need to do any updating. If a common library is pulled as a project dependency, then you'll have to do those bumps everywhere. Are you seeing this to be a common pattern?

Let's split the idea of making transitive dependency upgrades explicit off as a separate issue so that we can discuss it further.

The original issue here has practical implications for the correctness of the generated POM and Gradle Metadata and needs to be addressed.

So normally, a bad version will be caught as it will fail to find a prebuilt with the version. This happened to work because a lower level dependency had the correct version, but the higher level version did not. This is not a very likely scenario.

Given that we have catch this via jetpad not allowing an invalid version, this seems like P2 is the right level of severity to solve this.

There is a Gradle flag that prevents a higher version from being used in a project's classpath