Status Update
Comments
jo...@gmail.com <jo...@gmail.com> #2
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.
at...@google.com <at...@google.com>
at...@google.com <at...@google.com> #3
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.
- these requirements:
-
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
at...@google.com <at...@google.com> #4
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.
at...@google.com <at...@google.com> #5
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
at...@google.com <at...@google.com> #6
The request in
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 b/146802533
Slightly different. Fixing
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.
Description
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
What type of Android issue is this? Reboot or Crash
What steps would let us observe this issue?
1. Issue happens randomly
What did you expect to happen?
Stable operation
What actually happened?
Random reboots several times a day
How often has this happened?
Frequently
What was the effect of this issue on your device usage, such as lost time or work?
Did not observe, or no opinion
Debugging information
Google Play services
com.google.android.gms
Version 231556044 (23.15.56 (190400-527597497))
System App (Updated)
Android System WebView
com.google.android.webview
Version 561513634 (112.0.5615.136)
System App (Updated)
Network operator: T-Mobile
SIM operator: MetroPCS
Filed by Android Beta Feedback. Version (Updated): 2.33-betterbug.external_20230301_RC01 (DOGFOOD)
To learn more about our feedback process, please visit