-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xamarin.Android 9.4.1.0 increase release apk size #3454
Comments
This comment has been minimized.
This comment has been minimized.
Steps followed to test
Expected behaviorWith Xamarin.Android 9.4.0.51, the resulting APK file is about 11 MiB:
With Xamarin.Android 9.3.0.23, the resulting APK file is also about 11 MiB:
Actual behaviorWith Xamarin.Android 9.4.1.0, the resulting APK file is about 18 MiB:
Preliminary investigationIt 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.
Additional dataAssembly size increases in the APK for Xamarin.Android versions 9.4.1.0 vs. 9.4.0.51
|
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? |
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). |
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? |
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. |
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? |
Once again, this raises a series of questions:
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 |
@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 :/ |
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). |
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. |
@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. |
@JonDouglas Thanks for your comment, but I do not have the feeling that you answered my questions. |
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. |
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 |
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:
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. |
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:
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. |
As of now, I still haven't received any answer to my questions. |
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: What is the reason to optimize your app then Xamarin, messes up everything? |
@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 |
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. |
+2.5% is for dlls. |
@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). |
@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. |
@MitchBomcanhao thanks for the confirmation |
I must wait for a stable release
The latest "stable" version has this bug. Do you have release date for a stable release? |
@radekdoulik |
Which version of VS did you use to get this difference? |
As mentionned previously:
|
I tried on VS Mac 8.3 preview (latest)- my app size is 28mb |
|
@brendanzagaeski @radekdoulik @JonDouglas |
@tranb3r I have opened new issue for the " |
Ok, I'll have a look at it. |
@EmilAlipiev, it does as the The remaining difference between 8.1 and 8.3 is probably caused by larger BCL libraries in the later version. |
@radekdoulik 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%. Or maybe I've made another mistake ? Could you please double check with another app and confirm my results ? |
Here is more data from our app (same code compiled with different versions of VS 2019) :
Here are our conclusions:
Could you please provide an explanation ? This is kind of serious for us. |
@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) |
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) !! |
after upgrade vs for mac ,release apk of new blank android project increase to 17 mb
The text was updated successfully, but these errors were encountered: