Bug 43500 - Android AOT embeds methods names in generated .so files; creates large APKs
Summary: Android AOT embeds methods names in generated .so files; creates large APKs
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 6.1.2 (C7SR1)
Hardware: PC Windows
: --- normal
Target Milestone: 7.1 (C9)
Assignee: dean.ellis
Depends on:
Reported: 2016-08-18 01:45 UTC by Jerome Laban
Modified: 2016-11-18 17:51 UTC (History)
11 users (show)

Tags: potentialC8SR2
Is this bug a regression?: ---
Last known good build:

Android binary size issue repro (362.43 KB, application/x-zip-compressed)
2016-08-18 01:45 UTC, Jerome Laban

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jerome Laban 2016-08-18 01:45:31 UTC
Created attachment 17098 [details]
Android binary size issue repro

Large applications, with lots of methods and particularly lots of async methods, lambdas, iterators and generic types makes AOTed binaries very large. All the full unmangled method names are included in the resulting *.so files.

C# features that generate display classes are particularly bad in this regard, as the names length is generally not a concern when part of the original .NET assembly.

In the attached sample, LargeAssembly is 974KB and SmallAssembly is 808KB, and while the only differences are classes names, the resulting AOTed binaries are respectively 4.4MB and 3.4MB. That's a lot of strings...

I recall iOS does not embed any symbol names in the generated binaries, so is there a reason these symbol names are stored in the resulting binary ?
Comment 1 Rodrigo Kumpera 2016-08-18 22:06:51 UTC
Hey Zoltan,

Is there anything that could be done about this with the current interaction of AOT on Android?
Comment 2 Zoltan Varga 2016-08-19 14:40:17 UTC
Passing the 'no-write-symbols' aot option will turn this off. We might also be emitting dwarf debug info, that could be turned off with the 'nodebug' option, but that will also turn off more than that.
Comment 3 Jerome Laban 2016-08-19 15:08:15 UTC
Thanks Zoltan !

For now, there seem to be no way to pass additional arguments to the Aot msbuild task, unless I'm mistaken.
Comment 4 Zoltan Varga 2016-08-19 17:02:44 UTC
Unfortunately yes.
Comment 5 Rodrigo Kumpera 2016-08-19 20:28:10 UTC

Looks like we got a feature request here.

Could we extend the msbuild aot task to allow passing extra args to it?
Comment 6 Jerome Laban 2016-08-20 02:04:17 UTC
Ho well, this very significant! Ildasm/ilasm being my friends, I'm now able to get AOTed binaries down to LargeAssembly at 801KB and SmallAssembly is 802KB.

I tried using both `nodebug` and `no-write-symbols`.

On more real scenario assemblies, I'm observing decreases from 21MB to 13MB, or another one from 11.9MB down to 6.2MB for Arm-v7a.

This impacts the on-disk size of installed apps, particularly for low end devices, as well as install time.

I have not measured it yet, but the AOT generation times seems a bit faster as well.
Comment 7 Jerome Laban 2016-08-20 02:13:25 UTC
Correction, my non-modified-task real-scenario files where having linker enabled, making them smaller.

Without the linker, it gives a good idea of the strings impact, where sizes are 39MB down to 13MB and 14MB down to 6MB.

The first assembly contains a lot of small methods, async methods, iterators, lambdas, etc...
Comment 8 dean.ellis 2016-08-22 09:10:47 UTC
Rodrigo, Jerome

Adding extra args to the AoT task should be fairly trivial. It probably won't make it for cycle8 though (the current Alpha).
Comment 9 Jerome Laban 2016-08-22 21:11:45 UTC
Thanks Dean,

That's unfortunate. The modifications makes a blank android app zip APK (with x86 and armv7a) go down from 15MB to 12MB, and on disk from 49MB to 25MB.

That looks quite major...
Comment 10 dean.ellis 2016-08-22 21:52:41 UTC

I'll see what I can do and keep you posted.
Comment 11 dean.ellis 2016-08-23 14:56:58 UTC

I submitted a PR to the xamarin-android repo with the proposed changes.

With this you will be able to use 



I've tested that locally and it seems to reduce the size of libaot-Mono.Android.dll.so (for example)

In theory... once that has merged you might be able to get the build artifacts from the jenkins build system and replace your


with those.
Comment 12 dean.ellis 2016-08-25 09:40:17 UTC
Fixed in xamarin-android/master/da070383
needs to be applied to the monodroid repo now.
Comment 13 dean.ellis 2016-09-13 14:20:55 UTC
Should be fixed in the latest monodroid/master/a5091c65
Comment 14 narayanp 2016-09-15 15:20:31 UTC
I have checked this issue with latest master xamarin.android-7.0.99 build and observed that by adding the given argument manually: 
<AndroidAotAdditionalArguments>no-write-symbols</AndroidAotAdditionalArguments> to the csproj file so that it utilizes the new MSBuild properties mentioned in the bug and resulting in reduction of size of APK and libaot-Mono.Android.dll.so file from 13 MB to 9 MB and 8.3 MB to 6.3 MB respectively.

Here is the screencast for the same.


Before fix merged into Master : http://www.screencast.com/t/lWN9B8Cb1

After fix merged into Master : http://www.screencast.com/t/4iqXBJZkO

Environment Info:
gist: https://gist.github.com/lal360/50958afb8c571762120c22b75644af6f

Please merge the fixes into C8 builds so that I can verify this issue.

Comment 15 narayanp 2016-10-03 14:58:14 UTC
As per Comment 10, I am marking this issue as verified as this issue is fixed in Master lane and C9 is not yet split from Master.
Comment 16 Brendan Zagaeski (Xamarin Team, assistant) 2016-10-20 02:52:47 UTC
## Note to the Xamarin.Android team

Apologies in advance for using the "REOPENED" status as the best available option to raise a question about release inclusion.

At the moment, these changes have not yet been backported to the Cycle 8 branch, but the target milestone is still set to C8SR1.  If it has been decided that this change will indeed land on Cycle 9, then feel free to just update the target milestone accordingly and reset the resolution/verification status.


## Side note: link to "artifacts from the jenkins build system"

In case it might be of interest, the continuous builds lane for Mac OS installer packages that includes monodroid/master/a5091c65 is here:

Comment 17 dean.ellis 2016-10-26 10:14:20 UTC
The target was changed to C9. So changing the status back to fixed.
Comment 18 narayanp 2016-11-18 17:51:29 UTC
I have checked this issue with latest Cycle 9 XA build and observed that the fix is merged into Cycle 9.

Screencast: http://www.screencast.com/t/ifmQiLIpKb

Hence, I am closing this issue.

Thanks !