Setting $(EnableLLVM) to true adds to the APK size increase of APKs built by Xamarin.Android 10.0.0.43 vs. 9.4.1.1

[brendanzagaeski]

This is a new item for discussion about size increases related to $(EnableLLVM), previously discussed in #3454. It seems that $(EnableLLVM) might have itself introduced a size increase, adding to the (perhaps expected) increases in size of the managed input assemblies.

tranb3r commented on Sep 5 #3454 (comment)

Apk size:

• vs 16.3.0 preview 1.0 : 24438 kB
• vs 16.3.0 preview 3.0 : 26688 kB

I'm using AOT+LLVM, and the average increase of .so files seems to be around 10.5%.
But interestingly, the increase of libmonodroid_bundle_app.so (bundle of the dlls) is only about 2.5%.
So maybe there is another issue specific to aot/llvm ?

About java bindings, I'm using a lot of nugets, and I have no idea how many of them contain java bindings. But pretty much every single .so file is increasing in size in the apk.

---

tranb3r commented on Sep 24 #3454 (comment)

Here is the correct comparison between 16.3-pre1 and 16.3-pre3:

As you can see, the size difference for so libs is quite important (+11%), much more than the impact on dlls (+2.5%), which results in apk size increasing by +9%.
This is why I think there is still an issue that needs to be explained / fixed.

Or maybe I've made another mistake ? Could you please double check with another app and confirm my results ?

---

tranb3r commented on Sep 25 #3454 (comment)

Here is more data from our app (same code compiled with different versions of VS 2019) :

VS2019	Xamarin.Android	APK (kB)	lib\arm64-v8a (B)	libmonodroid_bundle.so (B)	classes.dex (B)
16.2.0	9.4.0.51	24679	60196936	6579296	3207436
16.2.1	9.4.1.0	29321	76671880	7979888	3816684
16.2.4	9.4.1.1	24916	61047856	6656880	3208892
16.3.0	10.0.0.43	26687	67170624	6754992	3054440

Here are our conclusions:

• the original linker bug was introduced in xamarin.android 9.4.1.0 (shipped with vs 16.2.1 stable), resulting in a huge increase of apk size.
• the linker bug was then fixed in xamarin.android 9.4.1.1 (shipped with vs 16.2.4 stable), and the apk size was almost back to normal.
• however, for some unexplained reason, in xamarin.android 10.0.0.43 (shipped with vs 16.3.0 stable), the apk size increases again, mostly because of aot libs (the bundle of dlls also increases but less the aot libs ; and the classes.dex file size decreases).

Could you please provide an explanation ? This is kind of serious for us.

[tranb3r]

@brendanzagaeski Thanks for opening this issue.
Our setup is AOT+LLVM, but I've never assumed the issue is related to LLVM, and we probably have the same issue with AOT only.
We're going to check that and report more data asap.

[brendanzagaeski]

Preliminary investigation notes for the Microsoft team

Steps tested

1. Create a new master–detail Mobile App targeting Android, using the project template in Visual Studio Enterprise 2019 version 16.2.5.

2. Package the app in the Release configuration with AotAssemblies, EnableLLVM, and BundleAssemblies each set to true or false:

   msbuild -restore -p:Configuration=Release -p:AotAssemblies=true -p:EnableLLVM=true -p:BundleAssemblies=true -t:PackageForAndroid

Behavior

For comparison, relative size of tranb3r's APK for 10.0.0.43 vs. 9.3.0.23:
1.071

Relative APK sizes for the master-detail Mobile App template:

Aot	LLVM	Bundle	10.0.0.43 vs. 9.4.1.1	9.4.1.1 vs. 9.3.0.23
✅	✅	✅	1.085	0.984
✅	✅	🚫	1.077	0.986
✅	🚫	✅	1.020	1.039
✅	🚫	🚫	1.019	1.035
🚫	🚫	✅	1.053	0.981
🚫	🚫	🚫	1.043	0.985

Additional data: Raw APK sizes

Aot	LLVM	Bundle	APK size (kB) 10.0.0.43	APK size (kB) 9.4.1.1	APK size (kB) 9.3.0.23
✅	✅	✅	33,902	31,235	31,734
✅	✅	🚫	37,229	34,554	35,050
✅	🚫	✅	34,557	33,873	32,602
✅	🚫	🚫	37,883	37,191	35,918
🚫	🚫	✅	14,640	13,903	14,167
🚫	🚫	🚫	17,967	17,222	17,482

From 9.3.0.23 to 9.4.1.1, sizes shrunk by about 1.6%, except for AotAssemblies without EnableLLVM, which grew by roughly 3.5%.

From 9.4.1.1 to 10.0.0.43, sizes grew by about 4.5% with no AOT, about 2% with AotAssemblies, and about 8% with AotAssemblies and EnableLLVM.

Additional version information

Android NDK r19

[tranb3r]

@brendanzagaeski
It could be worth looking at the break down per cpu architecture.
Also, the classes.dex file size may vary between android versions (for different reasons), so it's also worth giving distinguishing between c# and java code.

[radekdoulik]

@vargaz do you know about any issue in mono regarding AOT/llvm sizes recently? between the XA versions 9.4.1.1 and 10.0.0.43 there was a bump of mono from 2019-06 to 2019-08 branch.

[tranb3r]

More data from our app (10.0.0.43 vs 9.4.1.1):

AOT	LLVM	APK	lib\arm64-v8a
✅	✅	+7.1%	+10.0%
✅	🚫	+1.4%	+2.6%
🚫	🚫	+1.3%	+5.4%

So indeed the increase is bigger when using LLVM.

Note: we're using NDK 20.

[tranb3r]

@brendanzagaeski @vargaz Any progress?

[Akademiksdc]

@brendanzagaeski @vargaz any updates on this issue?

[Akademiksdc]

@brendanzagaeski @vargaz what is the status on this ticket?

[tranb3r]

@brendanzagaeski @vargaz @radekdoulik
Come on guys, we need answers !!!

[Akademiksdc]

@radekdoulik @vargaz @brendanzagaeski

Could you please provide some updates, how it's going on?

[brendanzagaeski]

Apologies that there hasn't been much movement here. I'll ask a couple other folks about this issue to see if there's any news available about the plans for investigation.