IssueTracker

The ToT dependency was coming from compose:test-utils. Jeremy raised aosp/2254837 to pin this to a prebuilt.

Alternatively, we could have added explicit androidTestImplementation dependencies on ToT to ensure it's available during dependency resolution.

TL;DR If we express a constraint on androidx.thing:thing:$TOT_VERSION which maps to the tip-of-tree version for :thing:thing, then any occurrence of androidx.thing:thing:$VERSION where the constraint is present must also include :thing:thing somewhere in the transitive dependencies.

My understanding of this issue is:

• Project A's library code depends on prebuilt B.

• Project A's test depends on prebuilt B and also library C.

• Library C declares a constraint saying that B must be the same version as Library C.

• When resolving dependencies for Project A's tests, these tests depend on prebuilt B and library C, so library C's dependency information is also considered.

• Library C says it requires B of the same version.

• To reconcile:

  • these requirements:
    • the dependency on prebuilt B
    • the constraint for B to match the version of C
  • Gradle looks for a prebuilt of B with version matching C.

• No prebuilt of B exists with the same version matching Library C, so Gradle fails to resolve the dependency.

Is this right?

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Assuming we're aligned...

Yes however if library B (e.g. project("B")) exists in the set of dependencies and its version matches C, then Gradle will successfully resolve the dependency by "upgrading" prebuilt B to library B.

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Yes! Fixed, thanks

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

Slightly different. Fixing b/146802533 will necessarily involve fixing this issue, since emitting constraints into all projects will cause this issue.

Given that this was caused by tests using different dependency versions than the library's runtime dependencies, though, maybe this is broken-as-intended? The fix that Jeremy implemented was to pin the tests to the same version.

Marking as Fixed even though the general problem can still occur. Unclear that we need a systemic fix.

Thank you for reporting this issue. For us to further investigate this issue, please go over the data below carefully and provide the following additional information:

Important: all information is helpful and relevant

• Please provide a simple sample project that reproduces the issue (this gives us the closest test environment to yours which will help analyze your issue) by uploading the exported zip file of the project from Android Studio or a sample apk file. Note: Please upload to google drive and share the folder to android-bugreport@google.com, then share the link here.

Once this information is provided we will pass this along to our product and engineering teams for inspection, thank you.

Thank you for the update. We will share the sample app once it is shared.

Thank you for reporting this issue. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

Thanks again for the feedback! Our product and engineering teams have evaluated the issue and responded:

This is WAI (working as intended) and no there is no API to change the order. The rationale is that user saved networks are always preferred to suggested networks when both are free.

Thank you for the update. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

Thanks again for the feedback! Our product and engineering teams have evaluated the issue and responded:

No API or behavior changes in this area in Android 11. To clarify: are you saying that your app on Android was built with SDK 28 but was using the Suggestion API? The Suggestion API was introduced with Android 10 - SDK 29

Thank you for the update. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

Thanks again for the feedback! Our product and engineering teams have evaluated the issue and responded:

There is no way for an app to override user networks. The rationale is to focus on the user experience and prefer the networks which they provisioned. Please provide more information about why in your case prioritizing the app networks will provide the user with better experience?

Note that these tradeoffs are hard and sometimes to avoid the potential for abusive behavior by apps we make these tradeoffs. But we are always interested in hearing about specific use-cases which may help us to make changes in the long term.

Thanks for the update. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.

Thanks again for the feedback! Our product and engineering teams have evaluated the issue and responded:

Apps may not force the device to connect or disconnect to a particular network - that is by design. You mention that once you provision a network it doesn't get connected automatically. The point is that the device will evaluate that network and may connect to it if it believes that it is better than other options, and that there aren't user preferred networks available etc. A high level overview of the decision tree can be found at https://source.android.com/devices/tech/connect/wifi-network-selection.