Split custom assets by device ABI?

[jonathanpeppers]

Related to: #116

I was reviewing the code and I don't see a way to have custom files split up per ABI:

bundletool/src/main/java/com/android/tools/build/bundletool/model/targeting/TargetedDirectorySegment.java

Lines 52 to 55 in ae0fc01

	private static final String OPENGL_KEY = "opengl";
	private static final String VULKAN_KEY = "vulkan";
	private static final String LANG_KEY = "lang";
	private static final String TCF_KEY = "tcf";

But you can do it for language or other "dimensions".

I work on .NET (for Android), and we have .NET assembly files such as:

assemblies/MultipleArch.dll
assemblies/armeabi-v7a/SingleArch.dll
assemblies/arm64-v8a/SingleArch.dll

I was looking for a way to split up these custom files per architecture. Is there a way to do this? Thanks!

[ymakhno]

Unfortunately splitting assets by device ABI is not supported now and we don't have short term plans to support this.

[jonathanpeppers]

Thanks @ymakhno,

If I were to implement this feature, adding support for a path similar to assemblies/#abi_armeabi-v7a/SingleArch.dll.

Assuming I sent a PR and it made it in, would there need to be changes to Google Play's backend as well? Or would it work even if we had our own fork of bundletool?

[plecesne]

Any reason you can't put the .dll files under lib/?

[jonathanpeppers]

@plecesne thanks, I'll give the lib folder a try and see if it works.

[jonathanpeppers]

The lib folder seems like it has some expectations for .so files:

[BT : 1.2.0] error : Native library files need to have paths in form 'lib/<single-directory>/<file>.so' but found 'lib/HelloWorld.dll'.

In this case, we would want HelloWorld.dll in the base .apk. There would be only some assemblies that are armeabi-v7a or x86-specific.

[ymakhno]

Could you please provide a bit more information about these assemblies to be able to identify a better solution for the problem? Why are some assemblies architecture specific and some not? Do architecture specific assemblies contain native code inside, are they effectively native libraries?

[jonathanpeppers]

These are .NET assemblies that contain IL that drives languages like C# or F#. It isn't native code. Our Android support was originally a product called Xamarin that we are working on moving to be a general feature of .NET.

A developer's C# code in their app would generally work on any architecture, but some libraries are highly optimized per architecture. An example would be parts of the Base Class Libraries such as System.Private.CoreLib.dll.

[ymakhno]

Thank you for the explanation! Two more questions:

• How big are architecture specific dlls?
• How do you plan to use these dlls? Extract from APK to some folder and next load it or just read as InputStream from the APK itself?

[jonathanpeppers]

• I compared two small apps and I saw about 1 - 2.2MB of assemblies per architecture. Larger applications could have more, I would think.
• .dll files are stored uncompressed and we have native code that uses mmap to load them directly. This is similar to how extractNativeLibs="false" works, I think.

[ymakhno]

Thanks! Probably instead of me spamming you with questions it would be easier for me to just play with the technology to understand which assemblies are architecture-specific and which are not and how changes in code affect size of both. Could you please share a link to a good manual I can use?

[jonathanpeppers]

We are still developing this, but we have working samples with preview builds here:

https://github.com/xamarin/net6-samples

To build an app bundle, you can build the Android project:

dotnet build HelloAndroid -p:Configuration=Release -p:AndroidPackageFormat=aab

And you should be able to find the build output in bin\Release\.

If you want to play with Xamarin, in general, you might be better off trying the guides for the stable product here. But we don't have these architecture-specific assemblies today.

[ymakhno]

I've played with Xamarin a bit and understand your usecase better now.

Currently you put CLI assemblies under root folder inside aab. This folder by design contains files that should go to the main split and that's why files there are not splittable. But we can support platform targeting inside assets (like we already have for languages as an example) so in your case you will be able to put assemblies like presented below:

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

Does it work for you? Will you be able to move assemblies to assets instead of root?

[jonathanpeppers]

@ymakhno yes, we can move them to assets. It actually might make more sense than picking our own directory name in the root.

Do you think platform#abi_armeabi-v7a would work today, or would this need to be added? Thanks!

[ymakhno]

It won't work today, I'll try to land it into next bundletool release. Will update this ticket once done.

[ymakhno]

Unfortunately I found out that solution that I wrote above won't be as easy to implement as I thought initially. I'll keep the issue open to keep it on our radar, but a short term workaround I can propose at the moment is only one described in #116.

[jonathanpeppers]

Thanks. Are you suggesting to put the files under lib? #116 (comment)

Would we have to rename their extension to .so? I was hitting this error when I tried: #190 (comment)

[ymakhno]

I think if you rename to .so it will solve the problem, if you don't want Android Platform to treat this file as a library I think you can skip lib prefix and have something like assembly-core.dll.so.