Closed fsaffioti closed 5 months ago
This is very similar to: https://github.com/dotnet/maui/issues/9453#issuecomment-1217003859
Google Play splits up app bundles per architecture. Are you comparing the numbers Google Play shows for your app?
Alternatively, you can build for one architecture as mentioned at the link above. It will give you a rough idea of what will happen on Google Play. Let us know your results from doing this, thanks!
Hi @fsaffioti. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
@jonathanpeppers thanks for quick response and your help is really appreciated
Actually, I was mostly comparing the APK (the AAB is slightly smaller than the APK) and I wasn't looking at the APK size on Google Play. Instead, I was considering the APK size on Appcenter with our current settings, as we distribute the app through Appcenter to QA.
for the app in Xamarin.Android on Google play and Appcenter <AndroidSupportedAbis>armeabi-v7a;x86;arm64-v8a;x86_64</AndroidSupportedAbis>
apk is 34 MB
aab is 30 MB
for the app in .net7 Android with dotnet publish myapp.csproj -f net7.0-android -c Release -r android-arm64
AotAssemblies && AndroidEnableProfiledAot blank
apk 33.8 MB
aab 30 MB
for the app in .net7 Android with dotnet publish myapp.csproj -f net7.0-android -c Release -r android-arm64
and AndroidEnableProfiledAot =false && AotAssemblies blank
apk 53.8 MB
aab 50 MB
for the app in .net7 Android with with dotnet publish myapp.csproj -f net7.0-android -c Release
and AndroidEnableProfiledAot =true && AotAssemblies blank
apk 68.7
aab 64.4
for the app in .net7 Android with with dotnet publish myapp.csproj -f net7.0-android -c Release
and AndroidEnableProfiledAot =false && AotAssemblies blank
apk 140.4
aab 136.1
for the app in .net7 Android with dotnet publish myapp.csproj -f net7.0-android -c Release -r android-arm64 AotAssemblies=false && AndroidEnableProfiledAot blank apk 30.2 MB aab 26.8 MB
Summarize with android-arm64 yes i have the same size probably the default in xamarin.android is just one ABI
then i have noticed with AndroidEnableProfiledAot =true the APK/AAB is very large but documentation says exactly the contrary .
what's the different between AotAssemblies && AndroidEnableProfiledAot ? Should both be true for production? should both be blank?
We try to set the best defaults for you, where you can just leave the settings blank. Release
builds by default will be:
AotAssemblies
/RunAOTCompilation
(both do the same thing) are true. This enables AOT compilation, resulting in a larger app.AndroidEnableProfiledAot
is true. This only AOT's a portion of your app, code that would be commonly called at startup or in your app's main project. It makes an AOT'd app a bit smaller, but no effect if AOT is off.For your numbers above, make sure you compare a Xamarin.Android & .NET 7 app with the same values for AotAssemblies
and AndroidEnableProfiledAot
. Then AndroidSupportedAbis=arm64-v8a
is the equivalent of -r android-arm64
.
@jonathanpeppers just want to say that same app - the Maui version has less code
I have looked at all the properties that are set and I cannot spot a difference. There is definetely an issue there...
Any suggestions on what properties I should set to minimize size of the app apart from AOT?
@gabsamples6 are these numbers from Google Play? Or are you compiling a single architecture to estimate?
The comment above explains further: https://github.com/xamarin/xamarin-android/issues/8212#issuecomment-1647889490
Hi @fsaffioti. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
@jonathanpeppers these are not google play because we cannot ship the maui app till critical bugs are fixed :)..
We use Azure Pipeline to deploy to appcenter (for dev -uat etc) and those are taken from appcenter...
Interestingly - this is something I wanted to ask and I googled but could not find the answer and would be grateful.
in Xamarin forms we could set <AndroidSupportedAbis>armeabi-v7a;arm64-v8a</AndroidSupportedAbis>
in maui there is no UI that I can see to set the architectures
So now I am not sure what architecture I am building... is it something that I have to define in the pipeline and how - since there is no UI or do I just amend the csproj file manually?
We want to get to the bottom of this on why the Maui app size is nearly double.. and fix whatever we are doing wrong..
Appreciate your input
Yes, as mentioned here:
It is the RuntimeIdentifier(s)
property. By default it is RuntimeIdentifiers=android-arm;android-arm64;android-x86;android-x64
.
If you want to compare sizes Xamarin vs .NET 7, build each one for a single architecture like ARM64. This gives you an idea before submission to Google Play (final source of truth).
There is no doubt at all that a Maui app is way bigger than a xamarin one
Android application type
.NET Android (net7.0-android, etc.)
Affected platform version
.net 7 android
Description
I am upgrading my app from Xamarin.Android to .NET 7, but the APK/AAB size is twice as large as the one built with Xamarin.Android.
Building and archiving the APK with .NET 7 (dotnet publish myapp.csproj -f net7.0-android -c Release) or from VSMac 17 results in a size that is twice as large as the APK/AAB built and archived with Xamarin.Android 13.
how can i reduce apk/aab, in xamarin.android is 30mb in .net7 android is 65mb ?
Xamarin Android project configuration
vs .net7-android configuration
nuget packages used in main project
nuget packages used in submodules projects
runtimeconfiguration.json
Steps to Reproduce
dotnet publish myapp.csproj -f net7.0-android -c Release
Did you find any workaround?
no
Relevant log output
No response