This would actually be a workaround to LLVM bugs and the like. Currently I have Azure.Storage.Blobs that freezes the app using LLVM, so it would be great if I could opt to using Mono AOT for that library. In any case, if you can give me hints how to create an aab with some .NET libraries compiled with Mono AOT and some with LLVM, that would be very helpful, so I can test the concept and see if it works as a workaround.

@dellis1972 Would it for example be possible to do a targets file that replaces appropriate LLVM libraries with pre-build Mono AOT libraries? If so, where should I add such a targets file in the build process?

If you are interested in this, you might contribute to dotnet/android with a proof of concept. A PR showing your results: perf metric before/after would be enough we'd accept the contribution and help get it merged. 👍

Right now, this isn't something we're looking into, though.

@jonathanpeppers In any case, we are very happy to investigate combining LLVM and Mono AOT, but we would need some guidance how to proceed with testing such a scenario.

I would start with the "contributing" section here, learn to build .NET for Android, etc.:

• https://github.com/dotnet/android?tab=readme-ov-file#contributing

Hi Jonathan,
Thanks for the tips. However, this turned out to be relatively straightforward: We made an AfterTargets target file for _AndroidAotCompilation target that calls MonoAOTCompiler target without LLVM, and it works really well.

BTW, hopefully the recently reported Microsoft personnel changes do not impact MAUI Android too negatively. The game is now starting to work very well, and if you need any positive references on MAUI and/or MAUI Android, we are happy to help.