My android release apk size built using Flutter is around 150MB. I would like to upload this apk to the google play store but play store has a apk size limit of 100MB. In Android app development we create APK expansion files for such limit in steps shown in this link. Would like to know the steps in Flutter code to create and use similar expansion files and reduce the app size to below 100MB.
Update
This question is not related to large size of apk due to Flutter. The apk is huge because of the assets used in the app. Want to know the process of uploading such apps in Flutter. In native android development we have the option of expansion files as shown in the link. IS there a similar option for Flutter if not what is the process to upload such apps to google play store.
When building a release version of your app, consider using the --split-debug-info tag. This tag can dramatically reduce code size. For an example of using this tag, see Obfuscating Dart code.
Some of the other things you can do to make your app smaller are:
Remove unused resources
Minimize resource imported from libraries
Support a limited number of screen densities
Compress PNG and JPEG files
or
One way that i use to reduce my app size is to use;
flutter clean
before i run the build command;
flutter build appbundle --target-platform android-arm,android-arm64
Use an appbundle and you get 150mb
https://developer.android.com/guide/app-bundle
use Firebase Storage to download the content (12 cents per gig)
https://firebase.google.com/pricing
or follow the Expansion files inclusion in Flutter (it is very quiet at the moment)
https://github.com/flutter/website/issues/2215
use this command to create multiple small size apk then upload multiple apk in play store
flutter build apk --split-per-abi
Use Deferred components for app-bundle generation if you have larger apk in flutter.
This feature is currently only available on Android, taking advantage
of Android and Google Play Stores’ dynamic feature modules to deliver
the deferred components packaged as Android modules. Deferred code
does not impact other platforms, which continue to build as normal
with all deferred components and assets included at initial install
time
I agree with #RémiRousselet maybe you can check your assets and tell us if that's the case. But if it's not, then maybe it's a package issue.
But as an FYI, Flutter team has an answer for big size APK. Check this. Also check this to know the minimum size of Flutter that they came up with. It was stated that,
we measured the size of a minimal Flutter app (no Material Components, just a single Center widget, built with flutter build apk), bundled and compressed as a release APK, to be approximately 4.48MB.
Judging from that statement, the Flutter APK is really large and it has a fixed overhead size.
Here are some reference you can check regarding how to reduce APK size.
Reduce --release apk and ipa sizes
Would like an article which explains how to reduce APK size
Also check this StackOverflow question related to yours.
Related
I have been working on React-Native for 3 months. All these days I was building the app only for android platform and the size of AAB file was 36.5 MB, Today I built my app to iOS (IPA File). The size of IPA file is just 5.6 MB.
No code changes,
No new library installations,
But why both files have a huge difference in size?
Thank you!
App bundles(AAB) cannot be installed as Android apps on user devices. Instead, they are meant to be used for generating APK files for specific device configurations. Different APK files are generated for different CPU architectures by the Play Store, the huge size difference may be because it contains information that is required to create APK for multiple device configurations.
You can use bundle tools to generate APKs locally https://developer.android.com/studio/command-line/bundletool
I have a project that includes a couple of cpu architecture specific .so files - the biggest being the xwalk lib, which is 60MB for the v8a version and 37MB for the v7a version.
When we had split APK the arm-v7a app apk version would be around 38mb and the arm-v8a apk would be around 41mb, which makes sense - zipping the lib would result in 23MB and 20MB, respectively.
When using app bundles it seems that the generated APKs are not compressed at all. the 60MB and 37MB are added to the apk size almost unchanged, resulting in a 97MB apk for 64bit arm devices.
I get consistent result when using the bundletool to generate the apks for one specific device and when downloading from the internal app testing play store site which returns the apks also depending on the device.
Am I missng something here or are app bundles not the best option when containing .so files and one is better off using split APKs again?
What matters is not the file size of the APK, but the download size of your app and the size on device of your app.
When you build an App Bundle, by default Play will leave the native libraries (.so) uncompressed in the generated APKs. Although this leads to a bigger APK file, this results in:
Smaller downloads for users because the compression over-the-wire can be more efficient,
Smaller app size on the device because the Android platform can mmap the .so files directly into memory without having to extract them first into a directory (thus saving a copy of the uncompressed .so file on disk).
bundletool actually provides a command get-size which estimates the download size for you. In practice, this the size is often even smaller when better compression algorithms can be applied, but this is a best effort by Play.
Here's a video from Google I/O 2019 where they explain the difference between the different types of size you can measure (at 15:55), and what Play does to help reduce the size of apps.
Hope that helps,
How to know the minimum device requirements to run my app in terms of memory and space. Is it through the minimum API which is 21 in my app or I need to monitor or calculate something. For space I build the APK with proguard true and it is 32,628kb while when I install it 50.79MB. Shall I say minimum space is 50.79MB?.
Any help is appreciated.
it will be fine when you set requirement that this app requires API 21,and the size of your apk is important not your debug apk size, the specify size should be your released apk size.
As far as I know there is no rocket science behind that. Check this thread: Why does my app size on device differ than the APK or Play store size
Quoting from #PFROLIM:
When installing an APK in android system, what's installed is the DEX
file. Which contains your code, resources etc compiled as binaries.
Your dex is generally the same size of your apk, unless you have
resources not compiled in assets.
Well, we all know that. What's not widelly spread is that android
SAVES your original apk too. Perhaps for reinstalling in case of
errors or for some other reasons.
That's why the amount of memory of our apps is the double in system.
It's the sum of the size of the original apk and the installed dex.
I need to produce 2 apks, one for x86 and one for ARM. I do this with different versions of crosswalk, which internally uses cordova. All I need to do one the two projects are created is ./cordova/build --release and then sign the APK. The Google Play store docs mention a way of uploading both into a single app listing, but they assume I'm using the Android NDK, which I'm not. Will I need to start using it or is there another way to simply upload both apks?
Google does support posting of architechture-specific APKs: http://developer.android.com/google/play/publishing/multiple-apks.html. Note however that the documentation states, in bold:
we encourage you to develop and publish a single APK
So, if you take the single APK approach:
Just compile your native code into libraries (i.e. .so files) and place them in the following locations
<Project_Root>/app/src/main/jniLibs/armeabi/
and
<Project_Root>/app/src/main/jniLibs/x86/
The build process will package these in the appropriate manner so that your APK contains libs for both architectures. Then at runtime, Android will ensure that the architecture-appropriate library is loaded.
Note that the above assumes that you are using Gradle to build your APKs. If you are using the old ant-based build process, the locations are slightly different:
<Project_Root>/libs/armeabi/
and
<Project_Root>/libs/x86/
What is the difference between the different .apk outputs when building a signed apk from IntelliJ IDEA?
When I do a signed apk build from IntelliJ Idea (13.1.2) I get three different apk files.
../myApp.apk (921 KB)
../out/production/myApp/myApp.apk (914 KB)
../out/production/myApp/myApp.unaligned.apk (1412 KB)
My guess is unaligned is non compressed and shouldn't be used in the play store. Which one should be used in the playstore?
Note: I am using proguard but not using Ant or Maven.
Use the one you find at .../out/production/Your App name/yourapp.apk
Yet again, in properties of the project you can set the custom location for your APK. But I suggest you get used to the default ones since it will be a pain to set up your path each time.