[Xamarin.Android.Build.Tasks] fix duplicate .aar files
#8196
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Context: dotnet/maui#16024 (comment) .NET MAUI's build currently fails with: Xamarin.Android.Aapt2.targets(123,3): error APT2144: invalid file path 'D:\a\_work\1\s\src\Core\src\obj\Debug\net8.0-android\lp\129.stamp'. What is very wrong about this, it is trying to `aapt2 compile` a `*.stamp` file: Executing compile -o /Users/builder/azdo/_work/1/s/src/Core/src/obj/Release/net8.0-android/lp/87/jl/res/../flat/ /Users/builder/azdo/_work/1/s/src/Core/src/obj/Release/net8.0-android/lp/87.stamp Normally this runs against `*.flat` or `*.flata` files. This problem was introduced in 26ffd5d: 1. Library A uses an AndroidX package, the AndroidX `.aar` file is added to `@(AndroidAarLibrary)`. The NuGet package does this in a `.targets` file. 2. With the change in 26ffd5d, the `.aar` is copied to Library A's build output. 3. Library B uses the same AndroidX package and references Library A. 4. Library B now has duplicate `.aar` files & has the weird build error! I could reproduce the issue in a test. There *may* be a second bug here, but we should update our logic to be: <!-- .aar files should be copied to $(OutputPath) in .NET 6--> <None Include="@(AndroidLibrary)" Condition=" '%(AndroidLibrary.Extension)' == '.aar' " ... /> <!-- @(LibraryProjectZip) items that are not in @(AndroidLibrary) --> <None Include="@(LibraryProjectZip)" Exclude="@(AndroidLibrary)" ... /> So we now only copy: * The new `@(AndroidLibrary)` item group with an `.aar` extension. *Not* `@(AndroidAarLibrary)`. * Any `@(LibraryProjectZip)` that are *not* in `@(AndroidLibrary)`. This supports the classic item group name, keeping our behavior before. Now the new test and the test updated in 26ffd5d both pass.
pjcollins
approved these changes
Jul 18, 2023
|
The policheck issue looks like it may be caused by a recent update to the tool, and should be fixed by #8197. |
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Jul 20, 2023
* main: [Xamarin.Android.Build.Tasks] fix duplicate `.aar` files (dotnet#8196)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Jul 24, 2023
* main: $(AndroidPackVersionSuffix)=rc.1; net8 is 34.0.0-rc.1 (dotnet#8204) Bump to dotnet/installer@ca467d68c8 8.0.100-preview.7.23364.32 (dotnet#8176) Clean up DotNetIgnore Unit Tests (dotnet#8163) [Xamarin.Android.Build.Tasks] fix duplicate `.aar` files (dotnet#8196) [Documentation] Appease PoliCheck Rule: 79604 (dotnet#8197)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: dotnet/maui#16024 (comment)
.NET MAUI's build currently fails with:
What is very wrong about this, it is trying to
aapt2 compilea*.stampfile:Normally this runs against
*.flator*.flatafiles.This problem was introduced in 26ffd5d:
Library A uses an AndroidX package, the AndroidX
.aarfile is added to@(AndroidAarLibrary). The NuGet package does this in a.targetsfile.With the change in 26ffd5d, the
.aaris copied to Library A's build output.Library B uses the same AndroidX package and references Library A.
Library B now has duplicate
.aarfiles & has the weird build error!I could reproduce the issue in a test.
There may be a second bug here, but we should update our logic to be:
So we now only copy:
The new
@(AndroidLibrary)item group with an.aarextension. Not@(AndroidAarLibrary).Any
@(LibraryProjectZip)that are not in@(AndroidLibrary). This supports the classic item group name, keeping our behavior before.Now the new test and the test updated in 26ffd5d both pass.