Adding any second AndroidLibrary/AndroidMavenLibrary-based content duplicates existing Firebase/GooglePlayServices namespaces (XAAMM0000)

[antizilis]

Android framework version

net10.0-android

Affected platform version

36.1.69

Description

When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via (or its wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — dotnet list package --include-transitive resolves exactly one version of every package involved, both with and without the added library.

Environment:

• dotnet --version: 10.0.302
• Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
• Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
• Target: net10.0-android36.0

Expected behavior: adding a second /-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.

Steps to Reproduce

When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via (or its wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — dotnet list package --include-transitive resolves exactly one version of every package involved, both with and without the added library.

Environment:

• dotnet --version: 10.0.302
• Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
• Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
• Target: net10.0-android36.0

Expected behavior: adding a second /-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.

Did you find any workaround?

No response

Relevant log output

When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via <AndroidLibrary> (or its <AndroidMavenLibrary> wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — `dotnet list package --include-transitive` resolves exactly one version of every package involved, both with and without the added library.

Environment:
- dotnet --version: 10.0.302
- Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
- Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
- Target: net10.0-android36.0

Expected behavior: adding a second <AndroidLibrary>/<AndroidMavenLibrary>-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.

[jonathanpeppers]

Can you share a sample project, or at least a snippet of the relevant part of the .csproj file? Thanks!

[dotnet-policy-service]

Hi @antizilis. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[antizilis]

Update: I found the actual trigger, and it's not AndroidLibrary/AndroidMavenLibrary at all — I apologize for the incorrect original report.

The real cause is an explicit PackageReference to Xamarin.AndroidX.Lifecycle.LiveData.Core version 2.11.0.1 that I had added (to resolve an unrelated NU1107 version-range conflict from an earlier iteration of my project). Confirmed with a fresh, minimal dotnet new maui project:

MAUI app + Plugin.Firebase.Core 4.2.0 + Plugin.Firebase.CloudMessaging 4.0.1 — builds clean.
Same, plus — fails with the exact same XAAMM0000 "namespace used in multiple modules" on the same 15 com.google.firebase./com.google.android.gms. namespaces. Reproduced 3/3 clean builds.
My original "second AndroidLibrary/AndroidMavenLibrary project" repro only failed because I happened to also be carrying that same pin alongside it — removing the pin, the second library builds in fine with zero errors.
So the actual bug is: explicitly pinning Xamarin.AndroidX.Lifecycle.LiveData.Core to 2.11.0.1 alongside Plugin.Firebase.Core/Plugin.Firebase.CloudMessaging causes duplicate Firebase/GooglePlayServices namespaces during manifest merge, with no second library/binding project needed at all.

I no longer need that pin with my current dependency set, so this is unblocked for me, but the underlying manifest-merge behavior still looks like a genuine bug (pinning a transitive package to a newer, still-compatible version shouldn't cause existing libraries to be processed twice). Updated repro steps:

dotnet new maui -n Repro
Add to the .csproj (Android-only is fine):

dotnet build -f net10.0-android — fails with XAAMM0000 on com.google.firebase/com.google.android.gms.* namespaces. Remove the Xamarin.AndroidX.Lifecycle.LiveData.Core line — builds clean. Happy to attach this smaller, corrected sample project if useful.