Xamarin.Android 9.4.1.0 increase release apk size

[hesamdarbandi]

after upgrade vs for mac ,release apk of new blank android project increase to 17 mb

VS bug #965880

[brendanzagaeski]

Steps followed to test

1. Create a new Android single view app.
2. Package the app in the Release configuration: msbuild -restore -p:Configuration=Release -t:PackageForAndroid.

Expected behavior

With Xamarin.Android 9.4.0.51, the resulting APK file is about 11 MiB:

  Length Name
  ------ ----
11334365 com.companyname.androidapp1.apk

With Xamarin.Android 9.3.0.23, the resulting APK file is also about 11 MiB:

  Length Name
  ------ ----
11575307 com.companyname.androidapp1.apk

Actual behavior

With Xamarin.Android 9.4.1.0, the resulting APK file is about 18 MiB:

  Length Name
  ------ ----
18837089 com.companyname.androidapp1.apk

Preliminary investigation

It looks like the fix for #3263 in 81627a4 is perhaps preserving all of the *Invoker types instead of only those that are actually required for the app.

• The difference in APK files size comes from the assemblies\ directory in the APK file.

• The file sizes in obj\Release\90\linksrc directory are OK.

• The outputs from the LinkAssemblies task in obj\Release\90\android\assets are problematic.

  Taking the smallest difference in the LinkAssemblies output as an example, the output from ildasm -noil -classlist shows the following differences for obj\Release\90\android\assets\Xamarin.Android.Arch.Lifecycle.LiveData.Core.dll:

   // Classes defined in this module:
   //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   // Class __TypeRegistrations            (auto) (ansi)
   // Interface IObserver                      (public) (abstract) (auto) (ansi)
   // Class IObserverInvoker               (auto) (ansi)
   // Class LiveData                       (public) (abstract) (auto) (ansi)
  +// Class ObserverWrapper                (abstract) (auto) (ansi) (nested public)
  +// Class ObserverWrapperInvoker         (auto) (ansi) (nested assembly)
   // Class LiveDataInvoker                (auto) (ansi)
   //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  For comparison, the matching file when using Xamarin.Android 9.3.0.23 does not include these 2 classes. Based on that result, it seems these types are not required by the app and that the managed linker is expected to remove them in this scenario

Additional data

Assembly size increases in the APK for Xamarin.Android versions 9.4.1.0 vs. 9.4.0.51

Increase in 9.4.1.0 vs. 9.4.0.51 (compressed bytes)	File name
4044288	assemblies/Mono.Android.dll
840192	assemblies/System.Xml.dll
666112	assemblies/Xamarin.Android.Support.Compat.dll
442368	assemblies/Xamarin.Android.Support.v7.RecyclerView.dll
389632	assemblies/Xamarin.Android.Support.Design.dll
275968	assemblies/Xamarin.Android.Support.v7.AppCompat.dll
109568	assemblies/Xamarin.Android.Support.Annotations.dll
82944	assemblies/Xamarin.Android.Support.CustomTabs.dll
67072	assemblies/Xamarin.Android.Support.Transition.dll
66048	assemblies/Xamarin.Android.Support.VersionedParcelable.dll
49152	assemblies/Xamarin.Android.Support.ViewPager.dll
40960	assemblies/Xamarin.Android.Support.CursorAdapter.dll
37376	assemblies/Xamarin.Android.Support.CustomView.dll
35328	assemblies/Xamarin.Android.Support.SwipeRefreshLayout.dll
34816	assemblies/Xamarin.Android.Support.Fragment.dll
25752	classes.dex
20992	assemblies/mscorlib.dll
19968	assemblies/Xamarin.Android.Support.SlidingPaneLayout.dll
16896	assemblies/Xamarin.Android.Support.Core.UI.dll
12800	assemblies/Xamarin.Android.Support.v7.CardView.dll
11776	assemblies/Xamarin.Android.Arch.Core.Common.dll
11264	assemblies/Xamarin.Android.Support.DocumentFile.dll
8704	assemblies/Xamarin.Android.Support.Animated.Vector.Drawable.dll
8704	assemblies/Xamarin.Android.Arch.Lifecycle.ViewModel.dll
8704	assemblies/Xamarin.Android.Arch.Lifecycle.Common.dll
7680	assemblies/Xamarin.Android.Support.CoordinaterLayout.dll
7168	assemblies/Xamarin.Android.Support.Print.dll
5632	assemblies/Xamarin.Android.Support.AsyncLayoutInflater.dll
4096	assemblies/Xamarin.Android.Support.Core.Utils.dll
4096	assemblies/Xamarin.Android.Arch.Core.Runtime.dll
3584	assemblies/Xamarin.Android.Support.Loader.dll
3584	assemblies/System.dll
3072	assemblies/Xamarin.Android.Support.Interpolator.dll
3072	assemblies/Xamarin.Android.Arch.Lifecycle.LiveData.dll
2560	assemblies/Xamarin.Android.Support.Vector.Drawable.dll
2560	assemblies/Xamarin.Android.Support.DrawerLayout.dll
2048	assemblies/System.Core.dll
1536	assemblies/Java.Interop.dll
1024	assemblies/Xamarin.Android.Arch.Lifecycle.LiveData.Core.dll
0	assemblies/Xamarin.Essentials.dll
0	assemblies/Xamarin.Android.Support.LocalBroadcastManager.dll
0	assemblies/Xamarin.Android.Support.Collections.dll
0	assemblies/Xamarin.Android.Arch.Lifecycle.Runtime.dll
0	assemblies/System.Runtime.Serialization.dll
0	assemblies/System.Numerics.dll
0	assemblies/System.Net.Http.dll
0	assemblies/Mono.Security.dll
0	assemblies/AndroidApp1.dll

[EmilAlipiev]

Is it not the case for VS mac 8.3 pre version? i see the app size is normal as expected using 8.3pre?

[brendanzagaeski]

Is it not the case for VS mac 8.3 pre version? i see the app size is normal as expected using 8.3pre?

Correct. The change in the linker behavior from the fix for #3263 in 81627a4 is not yet present in the current Xamarin.Android SDK version 9.5.0.27 in the Preview channel of Visual Studio 2019 for Mac version 8.3 Preview. That preview version was published on July 9, while the change in the linker behavior was added on July 19. The linker behavior change will be part of the next Xamarin.Android SDK version 9.5 preview, so that next preview will be affected by the size increase.

[FANMixco]

Is it not the case for VS mac 8.3 pre version? i see the app size is normal as expected using 8.3pre?

Correct. The change in the linker behavior from the fix for #3263 in 81627a4 is not yet present in the current Xamarin.Android SDK version 9.5.0.27 in the Preview channel of Visual Studio 2019 for Mac version 8.3 Preview. That preview version was published on July 9, while the change in the linker behavior was added on July 19. The linker behavior change will be part of the next Xamarin.Android SDK version 9.5 preview, so that next preview will be affected by the size increase.

Hi @brendanzagaeski , therefore, the new apps will be bigger? Or there will any solution?

[brendanzagaeski]

Based on my investigation so far, this issue #3454 is not expected behavior. The next Visual Studio 2019 version 16.3 Preview will include this bug. But I would expect for the issue to be resolved in a future Visual Studio 2019 version 16.3 Preview (and quite possibly a future Visual Studio 2019 version 16.2.x release as well).

[Magendanz]

Is there any workaround, so that we're not all stuck on 16.2.0 in the interim. Is there even a way to easily roll back the 16.2.1 update? And if we're forced to do a clean install, will VS Installer even let us install an older build?

[brendanzagaeski]

The team members who work on the managed linker can update about a workaround if I'm mistaken, but I am not aware of one so far. (As a side note, the extra types included in the APK shouldn't cause any other behavior problems when running the APK on device, so these larger APKs would be OK to distribute in cases where the extra size itself isn't a concern for the application's user base.)

Previous versions of Visual Studio 2019 Enterprise and Visual Studio 2019 Professional are available on https://docs.microsoft.com/visualstudio/releases/2019/history. Those installers do require uninstalling the previously installed version.

Previous versions are not available for Visual Studio 2019 Community. The links for the Xamarin.Android SDK version 9.4.0.51 package are available for Windows and macOS, but replacing just the Xamarin.Android SDK package is not a standard scenario. See #3112 (comment) for a few more details about that approach.

[ElteHupkes]

Phew I'm glad I found this issue. Our app size increased from 25mb to 32mb overnight, after I enabled and tested everything with d8 and r8... Once I realized that the app size on the current master was also a lot larger I came here, and there you go.

They're not earth shattering size increases but it is kind of annoying. Any time frame on when this might be addressed?

[tranb3r]

Once again, this raises a series of questions:

1. Why releasing a new preview of Visual Studio, when knowing that one of the key features of Xamarin.Android is broken ? Why not postponing this release instead of introducing such a blocker? My understanding is that a new release should be as stable as possible, only new features should potentially be broken (intentionnally).
2. The xamarin team has been advertising many new features recently. This is great, however I think there should be a lot more focus on stability, instead of encouraging people to update VS in order to get awesome new features, when the basic functionalities are broken. I mean, what's the point in getting profiled aot if the linker is broken !! This is totally counter-productive.
3. The releases notes of visual studio do not mention there is such an issue in the new release. Moreover, the release notes of xamarin.android were available only a few hours after the release was published and advertised. I think it's important to make sure that the release notes of VS have a big warning when such a regression is known and shipped.
4. Why isn't there a way to downgrade VS or to re-install a previous version of visual studio (preview, community) ?
5. The exact same scenario has occured a few weeks ago, when AOT was broken for xamarin.android in one of the VS preview release. No mention in the release notes, no workaround, no way to rollback, and it has taken several weeks to get a fix. Such a waste of time.... and lesson not learned.

Let's hope the VS and Xamarin teams will take this issue seriously, release a fix immediately, and take this opportunity to improve their processes at the same time...

cc @pierceboggan
cc Jacqueline Widdis (are you on github?)
cc Maddy Ledger (are you on github?)

[EmilAlipiev]

@tranb3r it can't be put in words better way. There is also this thing, Xamarin team keeps sending us surveys regarding "what can we do better to increase productivity". Answer is keep VS and Xamarin.Android updates stable or if not, react on vital problems faster. This bug costed me a lot of time. Because i initially though, i messed up something in my code or 3rd party nuget updates. i was comparing my branches, commits in recent days, uninstalling 3rd party nuget updates and finally found out that it was caused by VS update. how awkward is that :/
I have sent a personal email to @davidortinau with all VS2019 and VS4Mac issues with links. it is just unbearable if your IDE isn't working as expected and no easy way to go back to previous. I don't really care if any nuget update is broken, i can live with the older version but not when IDE.

[MitchBomcanhao]

The exact same scenario has occured a few weeks ago, when AOT was broken for xamarin.android in one of the VS preview release. No mention in the release notes, no workaround, no way to rollback, and it has taken several weeks to get a fix. Such a waste of time.... and lesson not learned.

This reminds me of the Profiled AOT for android, which was broken on windows on the first preview release. It seems like they use Macs quite a lot and release stuff that works on Mac but not on windows, and don't even mention that it is broken in the release notes. "hey here's this new thing", then you spend a chunk of time trying it out and it just doesn't work, only to find that it is fundamentally broken and they knew about it in advance (by reading the issues in other projects).

[JonDouglas]

Hey everyone,

We apologize profusely for this regression being introduced into Visual Studio 16.2. While the backing fix that introduced this behavior was intended to solve a number of crashing issues that had been previously reported, we sadly did not notice the consequences in which inflated package size as described by @brendanzagaeski in previous comments.

We are investigating alternative approaches, and will be working diligently to include a fix in a future service release and preview release of Visual Studio while ensuring this does not happen again. We will keep you updated as progress is made, and we are extremely grateful for your patience.

We appreciate all of the feedback regarding concerns with quality and I want to assure you that this is at the forefront of our minds when we ship updates to the product.

If there is any other feedback, comments, or concerns that you would like to discuss, please do not hesitate to email me at jodou @ microsoft.com.

[EmilAlipiev]

@JonDouglas thank you for the honest words. done is done. we should learn from it. I think that it would be nice to push such bug fixes into pre first where people can test and deliver feedback because this bug was affecting very little amount of people but consequences effected almost everyone. Now my question is i see that there is new 8.3 pre 2 update for Mac. is that Android size bug included? in the release notes i dont see anything in "known issues". Because 8.3 pre 1 doesnt have that bug and i would like to stay on this if pre 2 includes the bug.

[tranb3r]

@JonDouglas Thanks for your comment, but I do not have the feeling that you answered my questions.
If "quality is at the forefront of your minds" as you've said, why did you release a preview of 16.3 yesterday, knowing that it would include the same regression that was reported a few days ago in 16.2 ?

[brendanzagaeski]

Now my question is i see that there is new 8.3 pre 2 update for Mac. is that Android size bug included? in the release notes i dont see anything in "known issues".

At the moment, the known issues for Xamarin.Android are distributed across the Visual Studio release notes and the Xamarin.Android SDK release notes. For this particular case, the known issue in the Xamarin.Android SDK version 10.0 preview can be found in the Xamarin.Android SDK release notes on docs.microsoft.com and GitHub. I have some ideas for things to try to make the list of known issues for the Xamarin.Android SDK easier to find and browse in the future.

[brendanzagaeski]

why did you release a preview of 16.3 yesterday, knowing that it would include the same regression that was reported a few days ago in 16.2 ?

For the question about why the fix for #3263 was included in yesterday's Visual Studio 2019 version 16.3 Preview release, another team member can correct me if I'm mistaken, but I think for this specific scenario where a problem is introduced by a fix in a servicing update in the Release channel rather than in a minor update (terms borrowed from the release rhythm document), the fix will always also have been committed to the master and current Preview branches to maintain branch consistency (for both better and worse). In this particular case, in addition to the branch consistency, there would potentially also be trade-offs to weigh between addressing the issue with missing *Invoker types (which could cause apps to crash at an unexpected point, potentially on a relatively rarely used code path) versus increasing the Release configuration APK size by several megabytes (which is perhaps easier to notice than a crash on certain code paths). That trade-off would need to be weighed in the Preview version context, taking into account that the version is not yet "go-live" and not yet intended for use in production code (terms borrowed from the Visual Studio release notes).

[FANMixco]

If "quality is at the forefront of your minds" as you've said, why did you release a preview of 16.3 yesterday, knowing that it would include the same regression that was reported a few days ago in 16.2 ?

Another team member can correct me if I'm mistaken, but I think for this specific scenario where it's a servicing update in the Release channel rather than a minor update (terms borrowed from the release rhythm document), the fix will always also have been committed to the master and current preview branches to maintain branch consistency (for both better and worse). In this particular case, in addition to the branch consistency, there would potentially also be trade-offs to weigh between addressing the issue with missing *Invoker types (which could cause apps to crash at an unexpected point, potentially on a relatively rarely used code path) versus increasing the Release configuration APK size by several megabytes (which is perhaps easier to notice than a crash on certain code paths). That trade-off would need to be weighed in the Preview version context, taking into account that the version is not yet "go-live" and not yet intended for use in production code (terms borrowed from the Visual Studio release notes).

Hi @brendanzagaeski, the only issue that I see is that since a couple of releases ago in VS2019 as I emailed exchange with some people from Microsoft is that Xamarin.Android has become quite unstable.

I got a couple of emails asking me for providing my feedback about my experience with VS 2019 for Windows and Mac (because I have both) and I got in contact with some people from MS as I said before where they asked me to provide the full list of bugs that I have reported everywhere (GitHub, VS Developer Community and Xamarin Forums).

I've been using Xamarin.Android with VS2015, 2017 and currently 2019 and I am somehow astonished of the current situation. This is part of one of my emails:

"At this point of time, I'm having several mixed feelings about Xamarin.Android because it's quite unstable as a solution since I cannot release anything properly to production because each new release I should wait and see what the next collection of bugs is."

I can understand it's not prepared for production, but I'd say our concern is: When will we have a proper solution for production? I'm sure that even at my work where I have the Professional Version of 2019 installed, I would have a collection of bugs in the stable branch that it will be difficult to mitigate and justify many of them and to go backwards, I will need to start testing and uninstalling until I find, which version of VS is somehow working.

Also, I understand that is not easy to test a complex solution as Xamarin, there is a complex CI/CD, Unit Tests and probably a couple of integration tests, but I feel that something is missing since VS2019 was released.

[brendanzagaeski]

Just to clarify, my previous comment is only about the precise question of why the fix for #3263 is included in Visual Studio 2019 version 16.3 Preview 2. I've adjusted the wording of that comment to better reflect that.

[FANMixco]

Just to clarify, my previous comment is only about the precise question of why the fix for #3263 is included in Visual Studio 2019 version 16.3 Preview 2. I've adjusted the wording of that comment to better reflect that.

Hi @brendanzagaeski , you can take my case as an example since the #3263 is one of so many that I reported, but I repeat my words:

"At this point of time, I'm having several mixed feelings about Xamarin.Android because it's quite unstable as a solution since I cannot release anything properly to production because each new release I should wait and see what the next collection of bugs is."

And this is why I had email exchanges with MS people because as I said, I could go to my work and use the Professional Edition (not Community) where I have the benefit to rollback to a previous edition, but I will need to start uninstalling a massive application (specially in Windows) then install in it again and start testing for hours until I found one where is working properly. How many hours or days I need to spend for that? Maybe 2 or 3h per test. As in your case and my case, I don't think my manager would like to know that I'm stopping my entire work of a day or days because I need to reinstall each version of VS until I find which one works and which one doesn't.

Keep in mind that I gave the previous example to highlight the problem of the stability of the tool, but I'm sure something is missing in the QA section, either is the pressure of Android Q and Xamarin.Android 10 or something else, but I don't like the justification that you said that this is not a release to use in production because in my experience Stable ones as Previews are extremely unstable are alike at this point of time, when I reported the first bug it was in a Stable branch and then in the preview branch and then, I brought another bug that was in the stable, I use stable branches in Mac and Previews in Windows.

Someone asked about a possible timeline for the solution and this could be at least some light of where is going, I'm not sure the root cause of the current situation, but probably some tests are missing.

[tranb3r]

@brendanzagaeski @radekdoulik @JonDouglas
Any update on the aot/llvm issue ?

As of now, I still haven't received any answer to my questions.
I don't even understand why this issue has been closed.
I would really appreciate if you could take 1 min of your time to post an update.
Thanks.

[jorgenstorlie]

It should not be closed. Only workaround is to downgrade.

I used 1 day to figure out the reason my app increased in size. Read this:
https://devblogs.microsoft.com/xamarin/shrinking-android-app-size/

What is the reason to optimize your app then Xamarin, messes up everything?

[radekdoulik]

@tranb3r 2.5% increase with lots of java bindings looks right. Let see what makes the rest of the difference. Could you check the apk content?

The apk is a zip archive, could you get us the lists of both apk's, like output of unzip -l your-Signed.apk?

[MitchBomcanhao]

from my end, the current android build has gone back to the same size as it was before the issue was introduced, so it seems resolved, but i'm not using aot at all.

[tranb3r]

@tranb3r 2.5% increase with lots of java bindings looks right. Let see what makes the rest of the difference. Could you check the apk content?

The apk is a zip archive, could you get us the lists of both apk's, like output of unzip -l your-Signed.apk?

+2.5% is for dlls.
But more than +10% for .so libs (when using aot+llvm) !!
I'll provide the details you ask later, but again, it's such a waste of time...

[radekdoulik]

@jorgenstorlie the reason for the increased size is that linker became too aggressive at some point and removed too much. We fixed that and so it it is larger again, so we went back to the previous sizes.

Please make sure to use Xamarin.Android.Sdk 10.0.0.40 or newer as there was a regression introduced when we first fixed the issue (in earlier version).

[radekdoulik]

@tranb3r I will try to compare our sample sizes with AOT/llvm using version before the linker breakage and current version to see how it compares.

[radekdoulik]

@MitchBomcanhao thanks for the confirmation

[jorgenstorlie]

I must wait for a stable release

1. I use Appcenter to build my app.
   2)I will not use a preview version for release.

The latest "stable" version has this bug.

Do you have release date for a stable release?

[tranb3r]

@radekdoulik
Details for .so libs (16.3.0-pre1 vs 16.3.0-pre3) :

[EmilAlipiev]

Which version of VS did you use to get this difference?

[tranb3r]

Which version of VS did you use to get this difference?

As mentionned previously:

• vs 16.3.0 preview 1.0 : 24438 kB
• vs 16.3.0 preview 2.0 : ~30000 kB
• vs 16.3.0 preview 3.0 : 26688 kB

[EmilAlipiev]

I tried on VS Mac 8.3 preview (latest)- my app size is 28mb
using VS Mac 8.1 pre- 25 mb, VS Mac 8.2 pre 32mb.
yes there is an improvement on VS Mac but I dont know why there is this 3 mb more still. It isn't comprehensive for me why we should still preserve linker to remove this things. Because I never had any problem so far regarding what was reported? Does that problem really target all Xamarin apps or for some specific use cases? if it is some specific use cases, can there be a workaround using "skip" or "preserve" instead of preserving them for all users. we fight for every byte of app size and even 3 mb is something for me and it disturbs me to be honest

[tranb3r]

More information about my app:
I'm referencing Xamarin.Forms.DebugRainbows for debugging purpose, but in this version of the apk, I'm not using this dll (the code using it is commented).
So I'm expecting the linker to totally remove this dll, which was the case before the regression, but it's not the case anymore.
To me, it's one more proof that something is obviously wrong with the linker now.

[tranb3r]

@brendanzagaeski @radekdoulik @JonDouglas
I've been asking questions for several weeks now, and I don't have the feeling that this issue is being taken seriously.
What is going on ? Do you confirm the regression ? Can you fix it ?

[radekdoulik]

@tranb3r I have opened new issue for the "Xamarin.Forms.DebugRainbows not removed" problem as it should not be related to the *Invoker classes.

[tranb3r]

@tranb3r I have opened new issue for the "Xamarin.Forms.DebugRainbows not removed" problem as it should not be related to the *Invoker classes.

Ok, I'll have a look at it.
However, "DebugRainbows not being removed" is just a side-effect of the much problematic issue being the size increase of aot libs.

[radekdoulik]

Does that problem really target all Xamarin apps or for some specific use cases?

@EmilAlipiev, it does as the *Invoker classes can be called from java side of things and we don't have a way to tell whether they will be used or not. So they need to stay in as they did in previous versions.

The remaining difference between 8.1 and 8.3 is probably caused by larger BCL libraries in the later version.

[tranb3r]

@radekdoulik
I've made a mistake when comparing apks, I've used different versions of my code. Which explains the "DebugRainbows" issue.

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]

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.

@radekdoulik @brendanzagaeski @JonDouglas

[radekdoulik]

@tranb3r The dll size increase in newer versions is usually result of updated mono version.

I am still not sure about llvm, plan to look into it.

I wonder whether your app might profit from using the profiled AOT aka Startup tracing? That would reduce the size of your app while still keep the startup speed faster than JIT. (if that is the main reason for using AOT/llvm)
For command line usage check https://github.com/xamarin/xamarin-android/blob/d16-3/Documentation/guides/BuildProcess.md#packaging-properties and look for AndroidEnableProfiledAot property. For IDE see https://devblogs.microsoft.com/xamarin/faster-startup-times-with-startup-tracing-on-android/

[tranb3r]

I know about Startup Tracing, however this ticket is not about finding a workaround, it's about understanding why the apk size is increasing in the new version of VS (especially so libs) !!
Please reopen this issue and fix it !!!

[radekdoulik]

@tranb3r This issue was about the problem, which was side effect of *Invoker classes fix. That was already fixed by #3525

Lets discuss the AOT[/llvm] in the new issue #3724