I have been unable to find a list of runtime identifiers that were built for by default on .net 8. If I turn on all four RDIs

It sounds like you already found them, they are:

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

our .apk file jumps to over 73mb, whereas builds in .net 8 have always been approximately 43mb.

So, a difference between .NET 8 and 9, is we more strictly split up .NET assemblies per-architecture with app bundles. Previously, in .NET 8 you would end up with 4 copies of System.Private.CoreLib.dll for every arch, even though 1 would be loaded at runtime. Now all assemblies are split up, and Google Play only gives the set of .NET assemblies that run on that architecture.

Are you deploying on Google Play, or something else? You may be better off using Google Play's app size estimates as those will be more accurate than comparing the size of an .apk file.

Thanks Jonathan. It wasn't clear that .net 8 built for all those RDIs, only that those were all the possible RDIs.

We build one APK, and that is made available on Google Play and also on our own website.

not sure if google play will optimize an .apk... It might be better to use the .aab format for google play.
That won't help for a direct download though, you'll still need to use .apk for that.

We never migrated to .aab. Perhaps now is the time.

However, since we are not using an app bundle, I an unclear as to whether @jonathanpeppers theory would hold in this case.

If you have a single .apk for all architectures, it makes sense that it would grow between .NET 8 and 9.

So, I think your path forward is:

1. Use app bundles, Google Play already supports them. Requires them for new apps.
2. For your website, you can run bundletool to split the app bundle into 4 .apk files

The benefit for no. 2, is the download will be smaller, but either the user (or your website) will need to select the correct .apk.

The way this works, bundletool build-apks command creates an "apk set":

build-apks command:
    Generates an APK Set archive containing either all possible split APKs and
    standalone APKs or APKs optimized for the connected device (see connected-
    device flag).

Which is in .\obj\Release\net10.0-android\android\bin\com.companyname.helloandroid-Universal.apks if you want an example of one.

Then bundletool can create an .apk for each architecture with bundletool extract-apks using "supportedAbis": ["arm64-v8a", "armeabi-v7a"] mentioned here:

extract-apks command:
    Extracts from an APK Set the APKs that should be installed on a given
    device.

More info on this here:

• https://developer.android.com/tools/bundletool
• https://github.com/dotnet/android/blob/main/Documentation/guides/app-bundles.md

Thanks Jonathan. The website distribution is sufficiently niche that I don't mind the files being larger, and it certainly isn't worth my splitting them up to create separate downloads.

Presumably then, the nearly 70% growth in the .apk is just general bloat in all the .net libraries? There doesn't seem to be anything else left to explain it.

Sounds like I need to read up on migrating to producing app bundles.

.NET 9 has a copy of all .dll files per architecture.

.NET 8 shared most of the .dll files, except System.Private.CoreLib.dll.

Ah, I see. Thanks, that must explain it then.