Split up assembly store files in app bundles per architecture

[jonathanpeppers]

In .NET 6, we will have architecture-specific .dll files such as:

assemblies/armeabi-v7a/System.Private.CoreLib.dll
assemblies/x86/System.Private.CoreLib.dll

Right now bundletool has no idea that these files are architecture specific, and need to be split up. Android doesn't know what a .dll file is.

We need to see if there is a way to do this, offhand I can't find an example. Perhaps we can put the .dll files in a different path in the base.zip file?

There could potentially be runtime changes for this as well, as we will have assemblies in multiple .apk files when installed on device.

[jonpryor]

Two solutions have been suggested so far:

1. Figure out the BundleConfig.json file format and, if there is a way to say "the file assemblies/x86/System.Private.CoreLib.dll is only for x86 output", specify that. Or…

2. Put the per-ABI files into lib/ABI/assemblies, e.g. lib/x86/assemblies/System.PrivateCoreLib.dll. These files won't be extracted during App install (in Release apps; need to see behavior for Debug apps), but should still exist within the .apk files and thus should be "readable" by our .dll detection logic.

[jonathanpeppers]

Not immediately seeing a good way to do this, filed: google/bundletool#190

[jonathanpeppers]

The latest comment is we would be able to do something like:

/
|--assets
|   |--assemblies
|   |   |-- SQLLite-net.dll
|   |   |
|   |   |-- platform#abi_armeabi-v7a
|   |   |    |-- System.Core.dll
|   |   |
|   |   |-- platform#abi_arm64-v8a
|   |   |    |-- System.Core.dll

Only the assets directory supports splitting up files in a custom way. You can't do this with a custom directory name like assemblies in the root. This will be coming in a future bundletool version.

We should consider placing .NET assemblies in assets/.net/assemblies for all apps going forward. We were doing something similar for Embeddinator-4000 already, as we were generating an .aar file with assets/assemblies that could be consumed from Java/Kotlin apps.

[AmrAlSayed0]

@jonathanpeppers I think this issue is now irrelevant since .aabs are becoming mandatory in Google Play Store.

[jonathanpeppers]

@AmrAlSayed0 this issue is relevant because App Bundles are required soon.

These files are both in the base.apk for an App Bundle:

assemblies/armeabi-v7a/System.Private.CoreLib.dll
assemblies/x86/System.Private.CoreLib.dll

They are architecture specific, and they are installed on all devices. An x86 device, wouldn't need the other file.

So far the only suggestion we have from Google:

google/bundletool#190 (comment)

...is to rename assemblies to .dll.so files and put them in libs without the lib prefix:

libs/armeabi-v7a/System.Private.CoreLib.dll.so
libs/x86/System.Private.CoreLib.dll.so

This would mean they would hopefully be able to be split up by bundletool and the Android OS will not treat them as native libraries. You wouldn't be able to do loadLibrary("System.Private.CoreLib.dll").

I'm not sure when we'll get around to looking into this.

[grendello]

We've just had an idea of how to implement this. I'm going to put it here so that we don't forget.

The idea is to produce a stub, valid, shared library (.so) for each ABI and then append the per-abi assembly blob after the .so file end.
The .so would be placed in lib/[ABI] inside the AAB archive, which would make it possible for Google to move it to the per-ABI apk produced
when AAB is uploaded to the store. The shared library would never be loaded, we would instead mmap it like we do with the .blob files now, and
knowing the offset into the .so to the start of assembly blob, the process wouldn't be slower than what we do now.

The only question is whether there's any verification of the .so files on upload and, if so, whether the extra payload following the valid
ELF image would cause problems or not.

[jonpryor]

Edited subject to better represent the current state of the world, in which Assembly Stores are used by default in Release builds (c927026)

[jonpryor]

This is moot as of #8478 (and others): there is no longer an assemblies/ directory within the .apk. All assemblies are now stored in lib/ABI/lib*.so file(s).