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.
Related
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.
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.
Working with both app distributions services (android market and Apple App store) I have discovered a mystery.
The file size of an app is in general larger for an Apple app than for a Android app.
I can't seem to find any explanation for the differences, and it seems to be an untouched subject.
I have tried allot of different apps and the difference seems to vary between a couple of MB to 6-8 MB. So the question is, how come the file size is larger for Apple apps? What is the extra MB used for?
Examples:
BBC:
Android: 918K - https://market.android.com/details?id=bbc.mobile.news.ww
Apple: 6.7 MB - http://itunes.apple.com/dk/app/bbc-news/id364147881?mt=8
Due to some spam prevention, I'm unable to link directly to the rest.
British Airways
Android: 1.2 MB
Apple: 7.9 MB
Northern Bank
Android: 2.1 MB
Apple: 6.4 MB
Bank of America
Android: 727K
Apple: 2.1 MB
I could go on... If anyone can provide a statistics of file size for the two app distributions, confirming or disproving my theory. - I would appreciate it allot.
I have just spent the last day or so trying to track this exact problem down. I have built a little game called BlockIT for Android, and now I have a running version for iOS. The extremely odd thing is that the Android version is 8.2 MB and the iOS version is 14.1 MB.
Now, since I am the owner of the source, I wanted to track this down and find out why. As many suggest here that it is the graphical elements - this is not the case. The entire data set (non code) was almost identical in each package. Which makes sense since I am using the same graphics in each application.
So, why is the code build so much different! My iOS code build was nearly 7 MB and the Android one was less than 3 MB. The code itself was written to run identically and all but small portions of code are exactly the same on each platform. What I found was that the build (iOS gcc) settings had massive effects on what size of output you get. If you set only to target ARM6 or ARM7 then the size of my code binary dropped from 7 MB to 5 MB. This indicates there are almost complete duplicates of functions and libraries for each target in the one binary! Additionally, the built-in debugging symbols dont seem to get entirely stripped. Finally, the encryption of the code also costs large amounts. This is probably the most puzzling, since Android signs their apk's in a similar fashion. It seems that the iOS signing is done very oddly.
So, I hope that helps. To reiterate:
- Images / Data don't seem to be the problem
- Code building on iOS generates multiple platform output in the one binary == lots of extra code (btw I dont wee why Apple does this - seems odd).
- Code encryption is not very size friendly on iOS.
There's no real way to fix the actual problem (again, odd and disappointing).
The binary executable in an iOS app is encrypted, and thus compresses very poorly or not at all. The binary executable in an iOS app is compiled with some library code statically linked, which can often make it larger than interpreted Dalvik byte code for similar stuff. iPhone apps tend to contain more high quality graphics content and artwork for multiple screen resolutions including the relatively large iPad display.
For a universal app in iPhone we need to put three size of images -
one for 320x480 px
second for 640x940 px (retina)
third for 768x1024 (iPad)
where as while developing a android application we need to put three kind of images -
hdpi (high)
mdpi (medium)
ldpi (low)
one more thing here in android there is no compulsory rule to put all three kind of images. Basically it depends on for which target you are making app , only for those resolution we need to put images.
In my opinion, Apple Developers are using more full-screen size Images (in low def and Retina), and much more images than Android, and UI definitions files for iPhone (.XIB) are much bigger than XML files used in Android. There also should be a difference of Compression in packaging (.APK) is so hugely compressed ! And Finally maybe a difference in Including frameworks, but on this point I have no clue :)
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.
We have developed an app in medium(320x480) and high (480x800) supporting portrait and landscape. App has so many images so the build apk file size is 27 MB up to now.
Now client wants app in tablet version. If i do tablet version in the same project i think app size will be reach to more than 30MB.
Is there any problem if the app size reaches more than 30MB ?
Shall i do this tablet version in the same project or in different project. Please suggest me.
Thank you
Your application may not work as expected on Tablet if
1) you have used Android APIs that have been deprecated in HoneyComb version (Android version for Tablet). This begs using new APIs, worst case redesign.
2) you have tailormade UI widget for 320x480. This could include hardcoded resolution values, small resolution images used in UI widgets. In this case you need to redesign your UI Screen and fine tune it for Tablet.
3) your workspace in Froyo /Gingerbread. You need to migrate your application workspace to HoneyComb.
4) your app has put any limitation because of hardware. This I derived from the fact that your current app has been developed for 320x480 resolution, must be a slow hardware. But Tablet are powered by 1 - 1.5 GHz processors. You may need to have a look at new set of limitation (or freedom ?). For example memory limit on application may have gone up.
In short I would suggest have a different workspace for Tablet, however if your application has classes that are independent of above stuff, then you can share your package across application. (Tablet Vs Phone App).
Shash
Is there any problem if the app size reaches more than 30MB ?
If you are planing to upload your application to android market there is a file size limit of 50MB for an apk file. Other problems related to large apk files are listed in this SO question
Update:
Google updated their market policies you may refer this link