Closed kenneththorman closed 9 months ago
@jonathanpeppers Based on your previous comment at https://github.com/xamarin/xamarin-android/issues/5627#issuecomment-779880577
This may not be a common problem but it seems that you cannot be certain that aar files only will have files named "classes.jar" inside.
I am not in charge of either of the bindings
So I am not in control of the name of the file "repackaged.jar" (in this case) unless I want to modify the upstream package (which I prefer to not do).
Thank you in advance. Regards Kenneth
For now since I have a deadline looming, I will opt for the route of changing the name of the jar file and recompile the aar file, but this is something that I would prefer to not do, since I do not own the upstream package. It does allow for a lower priority on your end though.
The error is:
error XA1014: JAR library references with identical file names but different contents were found: repackaged.jar. Please remove any conflicting libraries from EmbeddedJar, InputJar and AndroidJavaLibrary.
This .aar
has libs/repackaged.jar
:
This also has it xamarin.androidx.emoji2.1.3.0.3.nupkg/aar/androidx.emoji2.emoji2.aar/libs/
:
https://www.nuget.org/packages/Xamarin.AndroidX.Emoji2/1.3.0.3
It feels like the XA1014
error should be removed? Or we make it ignore repackaged.jar
? @dellis1972 what do you think?
removing XA1014 would result in possible weird crashes at runtime. Its there for a reason. The problem here is repackaged.jar is probably required for both aar files? I think repackaging is probably the best bet. Also raise an issue upstream and try to get them to use a more unique name for that .jar file.
They don't seem to mention repackaged.jar
as the name of a special file here:
https://developer.android.com/studio/projects/android-library#aar-contents
Its not a special name, its just two different publishers used the same name, that contain different contents.
It would be very nice - if you decide to leave it as it is
It took a bit of digging to figure out what was wrong, since in the build log you see many duplicated jar filename, they just happen to be named "classes.jar". What caused me to further check before creating this issue was
(many developers are a bit reluctant to question Google, Microsoft offered packages, and then you spend time second guessing yourself)
@dellis1972 I will be showcasing my ignorance but I will ask anyway and appreciate any answer you can give
"removing XA1014 would result in possible weird crashes at runtime",
Why, and why not for classes.jar?
The code in classes.jar is the code compiled for that specific aar. This will generally have a unique package name so you dond't get clashes.
The files in libs are dependencies, so you can totally have two different packages referencing different versions of the same "third party" package. What you then end up with are two different jar files (one from each aar in the libs folder) which contain different code for the same classes/packages. There might be code in the classes.jar which depends on code in the jars in the libs, so if the wrong version is loaded you will see runtime exceptions.
Note in this line https://github.com/xamarin/xamarin-android/blob/336ec802edb628bdcd2f44df74652b0af684effc/src/Xamarin.Android.Build.Tasks/Tasks/CheckDuplicateJavaLibraries.cs#L33C33-L33C55 we check the content of the files not just the filenames. So in this case the repackaged.jar have different contents.
I believe that is why we put this check in to start with, but I'd have to look up the commit and check the commit message to be sure.
What you then end up with are two different jar files (one from each aar in the libs folder) which contain different code for the same classes/packages.
I think we may be protected against this error with the checks that javac
does:
Error JAVA0000 Error in C:\Users\user\.nuget\packages\xamarin.androidx.lifecycle.common\2.6.1.2\buildTransitive\net6.0-android31.0\..\..\jar\androidx.lifecycle.lifecycle-common.jar:androidx/lifecycle/DispatchQueue.class:
Type androidx.lifecycle.DispatchQueue is defined multiple times:
C:\Users\user\.nuget\packages\xamarin.androidx.lifecycle.common\2.6.1.2\buildTransitive\net6.0-android31.0\..\..\jar\androidx.lifecycle.lifecycle-common.jar:androidx/lifecycle/DispatchQueue.class,
obj\Debug\net7.0-android\lp\136\jl\classes.jar:androidx/lifecycle/DispatchQueue.class
Compilation failed
Responding to: https://github.com/xamarin/xamarin-android/issues/8326#issuecomment-1714291783
@dellis1972 Thank you for your answer
My question was unprecise and is in essence related to the reliance on the filename as deal breaker. The presence of the XA1014 error makes sense (either in implemented in MSBuild or relying on javac as posted in https://github.com/xamarin/xamarin-android/issues/8326#issuecomment-1714368161). The heavy emphasis on filename being the key factor in determining actual conflicting library contents, seems less than ideal.
Just changing the filename for libs/repackaged.jar and repackaging client-connect.aar resolved the XA1014 error, which seems to indicate that the filename is indeed the deciding factor. (It is hard to argue that repackaged.jar for Xamarin.Android bindings for AndroidX - emoji2 and Google Health Connect connect-client-1.1-alpha04.aar are real conflicting libraries)
There is a strong argument for rejecting files that do not follow the spec (like in this case "libs/repackaged.jar" https://github.com/xamarin/xamarin-android/issues/8326#issuecomment-1714069000), and for this to happen at the time you build a Java Library Binding project or at the time of approving/publishing a NuGet package (fail fast). Alternatively for at more tolerant approach, to only reject libs/jar files when they indeed have identical namespaced libs where the contents are different, and place less emphasis on the name of the libs jar file since the filename seems to be a poor indication of real conflicting libraries.
This should be fixed by: https://github.com/xamarin/xamarin-android/pull/8664
So this will be in .NET 9 Preview 1 and the next .NET 8 servicing release. Going forward you'll be able to add to the @(_AndroidExcludedDuplicateJavaLibraries)
item group to ignore errors. We're still deciding if it's worth checking for filenames at all -- historically, it was helpful for customers with duplicate .jar
files in class libraries and their app.
Android application type
Classic Xamarin.Android (MonoAndroid12.0, etc.)
Affected platform version
VS2022 17.7.3+34024.191, Xamarin17.7.0.216, Xamarin.Android SDK13.2.1.2
Description
In an Android project referencing the following
Building the project fails with
"error XA1014: JAR library references with identical file names but different contents were found: repackaged.jar. Please remove any conflicting libraries from EmbeddedJar, InputJar and AndroidJavaLibrary."
Steps to Reproduce
Add the following content to Transforms/Metadata.xml