Extraneous library artifacts included in archived Android APKs for incorrect platform (x64 in arm64 & vice versa)

[williamlewis]

Description

When we attempt an archive build for our .NET MAUI Android project, 3 apk packages are generated- one "fat" apk with both ARM64 and x64 architectures, and an architecture-specific apk for each platform.
The problem is that each architecture-specific apk seems to include library artifacts for the specific platform, EXCEPT for two files, which now appear for both architectures in ALL apk files: libassemblies.<arch>.blob.so and libarc.bin.so

Some research on these files yielded this blog post, which mentions:
With the release of .NET MAUI 9, a significant change was introduced in the way .NET libraries are packaged in Android applications. Instead of storing DLLs in separate files, all libraries are now embedded in ELF (.so) files named libassemblies..blob.so, where refers to the processor architecture, e.g., arm64-v8a.
https://mwalkowski.com/post/decompiling-an-android-application-written-in-net-maui-9-xamarin/

Question is- is this a build system bug? When we attempt to upload our individual architecture release apk files to the Play store, the second one is always rejected, as they see BOTH architectures already for the first file uploaded.

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

9.0.70 SR7

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

.NET 8 (Please specify exact version)

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

We have been able to manually delete the extraneous architecture lib artifacts from each APK, before signing. After doing that, the architecture-specific APKs are accepted by G Play Console.

Relevant log output

[jonathanpeppers]

So, I think generally you would upload a single app bundle to Google Play. Google Play knows how to split up an app bundle per architecture when users install your app.

Is there a reason you can't take that approach?

The problem is that each architecture-specific apk

Are you using $(AndroidCreatePackagePerAbi) to create these .apks or something else? This is an old setting that predates app bundles, so it may not work when using app bundles.

[carlosascastro]

@jonathanpeppers like I commented in issue #10357 the generation of a single apk (or app bundle) drops armeabi-v7a and x86 architectures and I guess that's the reason for the error and devices no longer supported reported by Google Play Console when I tried that approach to have my apps updated:

[jonathanpeppers]

@carlosascastro can you add all 4 RIDs if you need armeabi-v7a and x86:

<PropertyGroup>
  <RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>
</PropertyGroup>

.NET 9 dropped support for these by default in:

• 6be8531

[igristov]

@jonathanpeppers For various reasons, we need to sign the generated APKs ourselves rather than delegating this process to Google Play, so uploading in the App Bundle format doesn't work for us. In our project we use

<RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>
<AndroidCreatePackagePerAbi>True</AndroidCreatePackagePerAbi>

and in each generated .apk, in addition to the correct architecture folder, there are three extra folders for other architectures containing these two files: libarc.bin.so and libassemblies.<architecture>.blob.so.

Is there a simple workaround? Maybe it's possible to hook into the MSBuild pipeline before the APK is signed and remove these extra folders?

[carlosascastro]

I had the same issue as @igristov and the solution was to have a single apk and increase his version code so all the previous version codes for the different abi are able to update.

If I try the generation per abi, each generated apk identifies itself as satisfying more than one architecture and that generates an error on Google Play which looses the ability to update the app based on the abi and the version code branch (2000XX, 3000XX, 4000XX, 5000XX).

In .Net 10 the generation per abi will be deprecated and that gives me some comfort on the increase version code decision. I really hope this decision does not became an issue in future since we are totally dependent on Maui and pressured against the wall by Google policies to have the apps updated.

[jonathanpeppers]

we need to sign the generated APKs ourselves rather than delegating this process to Google Play

@igristov can you elaborate on why you need to do this?

We had considered deprecating $(AndroidCreatePackagePerAbi) at one point, so we need to understand what makes it useful.

[3-spot]

We also ran in to this issue. For reasons, we also have to sign the apks ourselves. We also distribute outside of the play store. We have a lot of native code and putting both architectures in one APK doubles the size to an unmanageable amount.

Our current workaround is to hook the build to fix the apks before the signing process. Like this;

<Target Name="_FixApkContents" BeforeTargets="_PrepareForSign" Condition="'$(Configuration)'=='Release'"> <Message Text="Removing extra files in APKs" Importance="high" /> <Exec Command='7z d -tzip obj\$(Configuration)\$(TargetFramework)\android\bin\com.example.app-arm64-v8a.apk lib\x86_64\*' /> <Exec Command='7z d -tzip obj\$(Configuration)\$(TargetFramework)\android\bin\com.example.app-x86_64.apk lib\arm64-v8a\*' /> </Target>

[jonathanpeppers]

We also distribute outside of the play store.

So, this is the reason, thanks.