IssueTracker

There is an issue about project dependency substitution when using the new API, I don't think we can migrate for now - https://github.com/gradle/gradle/issues/16694.

With changes in AGP 8.0 that stop aligning project dependencies (when external dependency is replaced in target configuration, we now don't apply the same substitution in the source configuration), AGP should be able to move to this API.

The only issue with migrating to Gradle APIs is AGP support for com.google.guava:listenablefuture:1.0 (https://issuetracker.google.com/131431257). If listenablefuture:1.0 is in the target configuration (the one we are aligning to), and if src configuration (the one we are aligning) uses com.google.guava:guava:27.0.1-android, AGP will avoid downgrading listenablefuture:9999.0-empty-to-avoid-conflict-with-guava to 1.0 as it causes duplicate classes issue.

I think there are 2 options:

1. rely on afterResolve to check if 9999.0-empty-to-avoid-conflict-with-guava was downgraded to 1.0 and fail the build asking user to add strict version constraint
2. do nothing, and let AGP duplicate class check task fail with duplicate classes defined in guava:27.0.1-android and listenablefuture:1.0. We could special-case this failure and again offer the snippet to add the version constraint.

I'm leaning towards 2) as it avoids paying additional cost for builds that are set up correctly.

The only configurations that we should align are runtime classpath of the android test component that should be aligned with the runtime classpath of the main component.

Fixed with I8a8e6c907814243c667dcc9c1c4b1bf7b99df48b

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 11
• Android Gradle Plugin 8.3.0-alpha11

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

With AGP 8.3, We seem to be hitting the issue predicted here: https://issuetracker.google.com/issues/172671706#comment4

we have listenablefuture:1.0 as a transitive dep in the debugRutimeClasspath config and listenablefuture:9999 as a transitive dep in the debugAndroidTestRuntimeClasspath config. We want it to choose 9999 (as it was in AGP 8.2), but it is choosing 1.0 with AGP 8.3.0.

"Consistent resolution" is adding a strictly 1.0 to the debugAndroidTestRuntimeClasspath adding constaints { } seems to lose out to consistent resolution, it still picks 1.0 ... Manually adding a strictly 9999 constraint via resolutionstrategy causes a resolution failure...

what is the right way to tell it that I want 9999 for just the androidTest configuration, (because only androidTest brings in full guava in this case)?

As a specific example:

Let's say you have a library module with implmentation(androidx.concurrent:concurrent-futures:1.1.0) (this brings in com.google.guava:listenablefuture:1.0) and androidTestImplementation("com.google.android.apps.common.testing.accessibility.framework:accessibility-test-framework:4.1.0") ( which pulls in com.google.guava:guava:31.0.1-android and then com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava )

I want guava in the test APK for the lib module. (and not listenablefuture:1.0 in the test APK because that would bring in duplicate classes ) the .aar should have a dep on listenablefuture:1.0

Same problem in the nowinandroid repo: https://github.com/android/nowinandroid/pull/1140

Is the issue you are facing the same as https://issuetracker.google.com/issues/316191239?

yogurtearl@, we have cherry-pick the change of "Not doing dependency alignment for test and tested runtimeClasspath in library" to 8.3.1 which would fix your issue.