net client: the fat-bundling of google libs makes building a net10-android app very difficult

[softlion]

Adding the OpenIa.Maui nuget (version 1.1.1) to a net10-android app breaks the build process:

<PackageReference Include="OpenIap.Maui" Version="1.1.1" />

The build process results in duplication errors like:

javac.exe error JAVAC0000:  error: class string is already defined in class R 

That is because the openiap nuget package includes google android bindings that are aready available through other nuget packages like Xamarin.GooglePlayServices.* (which are maui nugets, the xamarin name is misleading).

And for example including the nuget Xamarin.GooglePlayServices.Games.V2 will result in a duplication of these embedded libs.

So instead of fat bundling the google libs, add the existing matching nugets.

Workaround

To be able to build the android app using the 1.1.1 version of OpenIap I had to add this target to the dotnet 10 project:

 <Target Name="RemoveOpenIapDuplicateAars" BeforeTargets="_ResolveLibraryProjectImports"
            Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">
        <ItemGroup>
            <!-- Drop only OpenIap's bundled AARs that duplicate this app's existing bindings
                 (play-services base/basement/tasks via Xamarin.GooglePlayServices.*, transport-* via
                 Xamarin.Google.Android.DataTransport.*). play-services-location, billing*, and openiap*
                 are kept — nothing else provides them. StartsWith('play-services-base') covers basement too. -->
            <AndroidAarLibrary Remove="@(AndroidAarLibrary)"
                Condition="$([System.String]::Copy('%(Identity)').Contains('openiap.maui')) AND (
                    $([System.String]::Copy('%(Filename)').StartsWith('play-services-base')) OR
                    $([System.String]::Copy('%(Filename)').StartsWith('play-services-tasks')) OR
                    $([System.String]::Copy('%(Filename)').StartsWith('transport-')) )" />
            <!-- OpenIap.Maui.Bindings.Android.aar embeds its own gson, duplicating the GoogleGson binding
                 pulled in transitively (R8: "com.google.gson.* defined multiple times"). Drop the standalone
                 GoogleGson AAR so only one gson is dexed; the embedded copy serves the Java consumers.
                 No C# code here uses Com.Google.Gson (we use System.Text.Json), so this is safe — but
                 confirm gson-dependent paths at runtime on device (sub-task 7). -->
            <AndroidAarLibrary Remove="@(AndroidAarLibrary)"
                Condition="$([System.String]::Copy('%(Identity)').ToLower().Contains('googlegson'))" />
        </ItemGroup>
    </Target>

But I'm still not sure the android app will run.

[gitdogbot]

@softlion Thanks for the detailed report and the MSBuild workaround — this is a valid and actionable packaging issue.

What's happening:
OpenIap.Maui v1.1.1 bundles Google Play Services AARs (play-services-base, play-services-basement, play-services-tasks, transport-*, and gson) directly inside OpenIap.Maui.Bindings.Android.aar. When a .NET 10 Android app already pulls in those same libraries via Xamarin.GooglePlayServices.* or Xamarin.Google.Android.DataTransport.* NuGet packages, the dex/javac step sees duplicate class definitions (e.g., class string is already defined in class R).

The fix requested:
Instead of fat-bundling those transitive Google dependencies into the AAR, the OpenIap.Maui NuGet should declare them as <PackageReference> dependencies so NuGet's dependency resolver deduplicates them naturally. The AARs that should be replaced with NuGet references are:

• play-services-base / play-services-basement → Xamarin.GooglePlayServices.Base
• play-services-tasks → Xamarin.GooglePlayServices.Tasks
• transport-* → Xamarin.Google.Android.DataTransport.*
• gson (standalone) → Xamarin.Google.Gson (or exclude if only the embedded copy is needed)

AARs that should stay bundled (no existing NuGet equivalent): play-services-location, billing*, and openiap*.

The reporter's MSBuild workaround (for v1.1.1 until a fix ships) is reproduced in the issue and works correctly for build — though they note runtime validation on device is still pending.

A maintainer will need to update the OpenIap.Maui binding project (.csproj / AAR packaging configuration in libraries/maui-iap/) to declare the Google Play Services dependencies as NuGet <PackageReference> items rather than embedding the AARs, and then publish a new patch release.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

[softlion]

@GitDog
https://www.nuget.org/packages/Xamarin.GooglePlayServices.Location/ also exists. https://www.nuget.org/packages/Xamarin.Android.Google.BillingClient too.

net10.0-android36.0
Xamarin.AndroidX.Activity (>= 1.13.0)
Xamarin.AndroidX.Core (>= 1.18.0)
Xamarin.Build.Download (>= 0.11.4)
Xamarin.Google.Android.DataTransport.TransportApi (>= 4.1.1)
Xamarin.Google.Android.DataTransport.TransportBackendCct (>= 4.1.1)
Xamarin.Google.Android.DataTransport.TransportRuntime (>= 4.1.1)
Xamarin.GooglePlayServices.Base (>= 118.10.0.1)
Xamarin.GooglePlayServices.Basement (>= 118.10.0.1)
Xamarin.GooglePlayServices.Location (>= 121.3.0.9)
Xamarin.GooglePlayServices.Tasks (>= 118.4.1.1)
net9.0-android35.0
Xamarin.AndroidX.Activity (>= 1.13.0)
Xamarin.AndroidX.Core (>= 1.18.0)
Xamarin.Build.Download (>= 0.11.4)
Xamarin.Google.Android.DataTransport.TransportApi (>= 4.1.1)
Xamarin.Google.Android.DataTransport.TransportBackendCct (>= 4.1.1)
Xamarin.Google.Android.DataTransport.TransportRuntime (>= 4.1.1)
Xamarin.GooglePlayServices.Base (>= 118.10.0.1)
Xamarin.GooglePlayServices.Basement (>= 118.10.0.1)
Xamarin.GooglePlayServices.Location (>= 121.3.0.9)
Xamarin.GooglePlayServices.Tasks (>= 118.4.1.1)

[hyochan]

Checked and fixed in PR #184: #184

Gitdog got the high-level fix right: transitive Google dependencies should be NuGet dependencies, not fat-bundled AARs. Some package details were off, so the PR uses the actual Android NuGets (Xamarin.Android.Google.BillingClient, GoogleGson, AndroidX/Kotlin alignment deps) and verifies the generated nupkg only includes OpenIAP-owned AARs. I also reproduced a net10-android app with Xamarin.GooglePlayServices.Games.V2, and it builds cleanly.

[hyochan]

Deployed the final MAUI fix in OpenIap.Maui 1.1.3.

• Follow-up fix PR: fix(apple): accept apple purchase props #185
• GitHub Release: https://github.com/hyodotdev/openiap/releases/tag/maui-iap-1.1.3
• NuGet: https://www.nuget.org/packages/OpenIap.Maui/1.1.3

This includes the PR #184 MAUI net10 / Android packaging work and the PR #185 iOS purchase-sheet fix. The iOS MAUI bridge now accepts the canonical apple purchase/subscription props while preserving the legacy ios fallback, so MAUI iOS purchase requests can resolve the SKU and present the StoreKit purchase sheet.