I am encountering a fatal build error trying to resolve a reference for recent versions of Google’s ConstraintLayout library for Android. The most recent stable versions are 2.0.1, 2.0.0, and 1.1.3. I am able to build using 1.1.3 but not for 2.0.+. (But I have to use 2.0.+, since when I reference 1.1.3 in my main project, I get a “missing method” runtime error on a method that is apparently referenced by a different library I include).
Here is a sample project. It’s a clean new project with only a reference to the ConstraintLayout library added. As it stands, it generates 4 build errors “attibute ___ has already been defined”. Seems like possibly a merging issue? Reverting the gradle reference to 1.1.3 causes the errors to go away. org.gradlerefs.test.zip (29.3 KB)
Doesn’t look like it, as this happens on AAPT, long before we merge the manifest. this is the offending XM<:
<declare-styleable name="PropertySet"><attr name="android:visibility"/><attr name="visibilityMode"/><attr format="float" name="android:alpha"/><attr name="motionProgress"/><attr name="layout_constraintTag"/></declare-styleable> // aapt: Attribute "android:alpha" has already been defined
<declare-styleable name="Transform"><attr name="android:elevation"/><attr name="android:rotation"/><attr name="android:rotationX"/><attr name="android:rotationY"/><attr name="android:scaleX"/><attr name="android:scaleY"/><attr name="android:transformPivotX"/><attr name="android:transformPivotY"/><attr format="dimension" name="android:translationX"/><attr format="dimension" name="android:translationY"/><attr format="dimension" name="android:translationZ"/></declare-styleable> // aapt: Attribute "android:translationX" has already been defined
// aapt: Attribute "android:translationY" has already been defined
// aapt: Attribute "android:translationZ" has already been defined
I’m guessing constraintlayout-2.0.0 is not compatible with androidx, as this seems reminiscent of many errors I have seen when mixing legacy APIs with androidx. But thats just a guess.
I think I did determine the cause of the “method not found” error that prevents me from reverting to 1.1.3. When I revert to 1.1.3, constraintlayout requests constraintlayout-solver 1.1.3 but it resolves to 2.0.1. The method not found exception is
java.lang.NoSuchMethodError: No virtual method setWrapWidth(I)V in class Landroidx/constraintlayout/solver/widgets/ConstraintWidget; or its super classes (declaration of 'androidx.constraintlayout.solver.widgets.ConstraintWidget' appears in /data/app/~~6ZjXfVg7V1iyQtNqAdM0kg==/com.accordancebible.accordance-D1YSy9bMkXDJaIrM5lbUxg==/base.apk!classes18.dex)
It looks like constraintlayout 1.1.3 still pulls in constraintlayout-solver 2.0.1 internally, and constraintlayout-solver 2.0.1 is attempting to reference a method from constraintlayout 2.0.1 that did not exist in 1.1.3.
I suppose if I use the brackets to hard-limit which version a reference pulls, I would also want its references hard-limited as well, right? In this case I would at least need the option to do so.
Ah wait, there is a constraintlayout-solver package in my Ebuild/Packges/Gradle folder, just not in my intermediates folder. I have versions 1.1.3 and 2.0.1 in my local gradle folder, but it looks like neither is being pulled into the build although the build seems to expect it…
Just wanted to bring attention back to this since it seems like it was dropped. This is still a significant issue for me. To get it to work, I have to copy an old dependency into my gradle cache and rename it to make EBuild think it’s the latest dependency. Every time the dependency is updated remotely, I get a runtime crash and have to do it again.
I looked back at it and think I’ve figured out what needs to be changed. To use the example that I’m facing, androidx.constraintlayout:constraintlayout:1.1.3 has a dependency on androidx.constraintlayout:constraintlayout-solver:1.1.3. But even when I fix the version to [1.1.3] in my project file, constraintlayout-solver resolves to the latest (currently 2.0.2).
My suggestion is that if a dependency’s version is fixed with [version] then all of its internal dependencies should also be fixed to the version specified in the pom file.
The pom file for constraintlayout:1.1.3 lists its dependency on
I believe that is/was the case, but I’ll have a look and fix. Since this thread as gotten long, do you have a latest simple test case that lets me easily reproduce this and test the fix? If so, I’ll have a go at it this afternoon.
Assuming lVersion2 is an internal dependency of a requested dependency, I don’t see what could break that shouldn’t break… If a maven library specifies a specific version for a dependency in its pom file, I can’t think of a case where you should choose to use a different version than the one requested.
Note that if you’re on Mac and using the new external compiler with Fire, it wont affect the resolving you see in the IDE’s tree view (i.e. the numbers shown in your screenshot); only what happens when you do the actual build.
ConstraintLayout:1.1.3 requests ConstraintLayout-Solver:1.1.3. Allowing solver to bump to a newer version (for example, 2.0.2) causes a crash due to a resource mismatch. So in this case ConstraintLayout-Solver must be locked at 1.1.3.
AppCompat:1.2.0 requests Annotation:1.1.0 and also DrawerLayout:1.0.0. DrawerLayout:1.0.0 requests Annotation:1.0.0. So should you force Annotation to 1.1.0 or use 1.0.0?