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

[JonDouglas]

This was first introduced in Xamarin.Android 9.3. We did add an additional ABI to adhere to Google Play's requirements:

https://docs.microsoft.com/en-us/xamarin/android/release-notes/9/9.3#arm64-v8a-architecture-enabled-by-default

This looks to be a regression with the Linker in which it's preserving more types than it should.

[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?)