I am not sure, if I got this right. It seems it is doing the oposite. If I keep the flag android:extractNativeLibs set to true, the app is taking about 70MB of user's space (yeah...) but if I set this flag to false, the size of the app installed on the device jumps to about 95MB. So I am not sure if user would appreciate this.
This is a bit tricky. Your APK size is going to be larger when extractNativeLibs is set to false.
Old behavior
When extractNativeLibs is set to true (default) or not added to the manifest, your native libraries can be stored compressed in the APK. They are extracted by the PackageManager during installation, and a copy is put to /data/app/. As a result, there are two copies of the native library - a compressed in the APK, and an uncompressed in /data/app/.
This approach has the following advantages:
smaller APK size because the libraries are compressed
Drawbacks:
increased installation size ("storage" or "on disk" in Settings=>Apps) because in addition to the APK, the extracted native libraries are taking space on disk
longer installation times
less optimizations from Google Play, for example when generating update patches
New behavior
New approach introduced by Google in Marshmallow (Android 6) is enabled by setting extractNativeLibs to "false". It expects the libraries stored uncompressed in the APK (STORE method) and zipaligned. There's no need to extract them during installation. On app startup, the libraries can be loaded (memmapped) directly from the APK.
Advantages:
decreased installation size ("storage" or "on disk" in Settings=>Apps) because there's no need to extract the libraries. Basically, the occupied space is usually just a bit more than the APK size
no increase in the download size from Google Play, because it uses its own compression on top of APK
optimized update patch generation by Google Play, resulting in smaller update sizes. If you update your native lib, the compressed version will have huge differences causing a larger patch, while a patch for an uncompressed library is going to be relatively small.
Disadvantages:
larger APK size because the native libs are not compressed
Expectedly, I didn't find a noticeable difference in loading performance of both options.
Conclusion
The extractNativeLibs="false" option could be useful for your if:
you don't care about the APK size - either it is well under 100 Mb limit or you are already using expansion files (OBB) and can handle the APK size increase
you care about the update size of your app in Google Play
your native libraries are not very large.
For example, for a game made with Unity, this option is hardly applicable because of the large native libraries.
UPDATE: Android App Bundles
Android App Bundles are a new distribution mechanism announced by Google Play, more details available on the official websites https://developer.android.com/platform/technology/app-bundle/ and https://developer.android.com/guide/app-bundle/
It has significant advantages over a traditional APK, one of the most important being the 150 Mb max size limit. Important: this is the download size, not the size of the app bundle itself or the generated APK. (APKs are generated by Play and delivered to the device on-the-fly, more details on how it works should be available on official Android resources).
When building an AAB, it has the extractNativeLibs flag set to "false" by default. However, as Google Play applies compression on top of the APKs delivered to the end device, this doesn't affect the download size. It means that this flag brings only benefits in case of Android App Bundles - faster installation, less size on disk at almost no additional cost because of no pressure towards the max size limit.
One confusing thing however is how to calculate the download size when you're close to the 150 Mb limit, because the AAB size is not an indication of the download size. There is a special command for that in the bundletool https://developer.android.com/studio/command-line/bundletool#measure_size, or you can try uploading it to Play directly. If your AAB is well under 150 Mb, there's no need to worry then.
(Update: using 150 Mb size limit instead of 500 Mb for app bundles; apparently 500 MB was available in developer preview but is not public as of now).
extractNativeLibs="false" could be counterproductive if your APK contains multiple ABIs. Let's say you're using a library which is 10 MB for each ABI and can be compressed to 5 MB. If you have 3 ABIs, then the result is:
extractNativeLibs="true":
APK: 15 MB (3 x 5 MB)
Extracted: 10 MB
Total: 25 MB
extractNativeLibs="false":
APK: 30 MB (3 x 10 MB)
Extracted: 0 MB
Total: 30 MB
As of 2019, the recommended way to mitigate this is to use the Android App Bundle format.
There are some important preconditions for that to work though and that’s where things get more complicated:
The .so files inside the APK cannot be compressed — they must be stored.
The .so files must be page aligned using zipalign -p 4
Update: The part below is only valid for Android Studio version 2.1 and lower. Starting from Android Studio 2.2 Preview 2 and newest build tools, the build process will automatically store native libraries uncompressed and page aligned in the APK.
Fore more information: link
Update: If at some point you sign your app manually, it matters when you invoke zipalign.
Caution: You must use zipalign at one of two specific points in the app-building process, depending on which app-signing tool you use:
If you use apksigner, zipalign must only be performed before the APK file has been signed. If you sign your APK using apksigner and make further changes to the APK, its signature is invalidated.
If you use jarsigner, zipalign must only be performed after the APK file has been signed.
Source: zipalign | Android Developers
Android 6+ will prevent you from installing a misaligned APK with uncompressed native libraries. Older Android doesn't care and always extracts native libraries.
Related
I make a Android app.It have 2 Activities and 10 fragments.This is my first time to publish a app.When i first analyze the app its of small size.when i try to install through that apk.Device say its only for test.
When i build a apk and than analyze it, its size increase by 3 times.
I am confused why my app size increase.
The both screenshots how the reason: the first version contains only libraries for armv7 (32bit) and the other screenshots shows that the libraries for x86, armv7 and armv8 are included. The library has 11 to 15MB and including it three times increases of course the app size.
As each device only requires one of the libraries you can reduce the download size by splitting up your app into an app-bundle. An bundelized app is split into several parts and if a user installs the app Google Play downloads only those parts needed for the current device. Therefore only one of the three libraries would be loaded.
It seems that you used a native library for your app. The thing is, that native libraries are platorm-specific. A native ARM library can not be used for x86, and vice versa.
This way, Android Studio has to build the native library for the three more common architectures for Android: ARMv7, ARMv8, and x86. Hence the size increase. You can't - and should not - remove the extra architectures, because this can result in the app not working on some devices. This kind of size increase is unavoidable with the APK format.
Android App Bundles solve this problem by only downloading what's needed for the device. The guide on how to publish as a bundle is in the link.
Certain libraries must be installed according to the processor models of the phones.
When you publish as an App Bundle. It will be sufficient to load the resources according to the user's phone.
I'm a noob please help me out here. Now I'm aware Google has a new rule in making our Apk support for 64-bit. I have done that, but targeting for each architecture has led my Apk bundle size hit 44MB all the way up from like 15MB with Mono and it's default ARMv7 targetting on Unity. Does this mean my APK will be a size of 44MB when it hits Google Play Store? Or is that just a reflection of multiple APKs being chunks of that 44MB? I'm hoping that my individual APK for x architecture device will be still around that 15MB mark or so when the user has to download the application, so do I need to worry about this during the internal/closed tests and actual publishing?
Okay so turns out I would've got the answer anyway had I just uploaded the APK bundle as it was. So while it happens in the Google Play Console, Google estimates the actual size of each APK download size which will be between X - Y MB.
My generated APK is around 6MB.
I am using ProGuard.
However, after installed into phone device, it takes up space around 60MB.
I would like to know, which dependencies cause huge installed space (60MB)
I look at How to check the size of dependencies in an android app? and https://medium.com/google-developers/making-the-most-of-the-apk-analyzer-c066cb871ea2
I use "Build → Analyze APK".
But, it can let me know where does 6MB (size of APK) come from. But, it doesn't let me know, why it does take up to 60MB in user phone.
Google tooks most of the method counts.
But, I don't think Java code with ~40,000 methods and reference ~50,000 methods, can consume up to 60MB space.
I had checked my assets folder and res folders. Their size is 2MB and 3MB respectively. Hence, I have no idea what is the major contribution to 60MB app installed size.
Is there any good way, to inspect and reduce app installed size?
What should we do if the size of our Android application is more than max size? Currently the acceptable size for Android applications (i.e. <App>.apk) on the Android market is 50 MB.
If our <Application>.apk size is more than 50 MB then what's the alternative to follow on?
Try removing the resources from the project and changing the app so that the resources will be downloaded upon first app opening to the SD card...
It will take some time to develop the changes, but I don't think you really have a choice...
Note that Samsung devices have an even smaller size limit...
The first reason for .apk size growth is resources. The more specialized application gets on each configuration (screen sizes, orientations, densitites etc) the more .apk size grows. Usually .apk still has size much less then 50 mb limits, but even with 20mb users may perceive your application as heavy.
Android Market added support for multiple .apk per application. This feature was designed to specifically address the issue of .apk size growth due to many different configuration. You can read more about it in Multiple APK Support in Android Market post from official Android blog. Though this is considered as last resort.
If you .apk size is large due to other reasons, then you're most likely doing something wrong. If its some embedded video/audio file (or even files!), consider moving them to web and download when user needs them for the first time. This will save internal memory space which is might be critical to users (especially on older devices).
I can't image why an application would be more than 50 mb from just the source code alone. If alot of the size is in design elements(images, etc) or data(database files), you could always have the user download this info when the application is first run.
if you are using Android 2.3.3 version then minimum size of the application must be minimum 9MB and maximum size is depend upon the device,the capacity of memory of the device. but if you take it 50 MB then no problem, its disadvantage is only that the AVD takes time to start.i don't know the Android Market place current application size.
My app is around 1.5MB at the moment. Is that on the higher size?
What is the average size for an Android app and is there an upper limit placed on it by Google?
I don't know about the average or optimum size of an apk file but an apk file of or upto 50 MB is currently supported. As per the Android Market for Developer Help;
APK file size: Maximum supported size is 50MB.
Source: Android Market for Developer Help
Update (06 March 2012):
As of 05 March 2012, by using the new concept of APK Expansion File, an app (not an APK) can be as big as 4GB. See the Android Developers Blog for details.
I don't think there is upper limit in android app market. I have downloaded 25+MB applications without problem.
1.5MB is just fine.
I'm not sure of the reputability of this site, but the current limit is 50MB and will soon be 4 GB.
Although 1.5 MB is still pretty small in comparison, I would recommend optimizing as well as possible. People still have to download this and the sooner they have it the happier they are.