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.
Related
I had combed through a number of medium articles, the official Android documentation, and this thread to find ways to reduce the size of the hello world app generated by Android Studio. Unfortunately, the most common strategy, which is to enable Proguard to minify and shrink resources, hasn't done anything to reduce the size of the installed app. I'm also using the size of the app installed rather than the apk for my point of reference. And the size of the app generated comes out to a little over 5MB, which is over 5x more than what the person in the other thread cited. Any help would be much appreciated. I had tried installing this on a number of devices running KitKat, Lollipop and Nougat. I'm not sure if this is the cost of using a newer version of Android Studio (3.2.1) or newer tooling in general or if there are ways to optimize this code to bring this down to the size of Google Hangouts dialer, which is only 108KB (again, installed, not apk), even though it has considerably more assets and more functionality than a hello world app. Thanks.
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.
The other day I was inspecting "App Info" from an app I'm developing and to my surprise I detected an enormous amount of Mb were being used as "cache" (the app didn't download any content yet, it was just a mockup). At first I thought I could be some heavy libraries I'd added (fresco..) so I decided to create a blank project an try to figure out what was the problem.
I've tried 2 scenarios: pre-lollipop and lollipop. With this I found out there is some difference with the way they handle "data" but the overall apk size was the same. Though here, in pre-lollipop (4.4.4) there was almost no "cache"(FIRST IMAGE) in lollipop... well 8 mb of "cache".
All of this wasn't enough since the other apps I'd developed in lollipop and above had way less "cache". I started thinking what could be the difference and finally I think I've found somthing, gradle version!
The project build with gradle 1.5 has smaller apk size and almost no "cache" (both lollipop and pre-lollipop)
Is there something I'm missing? Why the sudden increase in "cache" size.
Is there any way to avoid this while using the latest gradle version?
Instant Run ships incremental chunks of your app, reflecting changes that you made to the code. That stuff still needs to be loadable by your app, so they apparently are putting that information in some location that gets counted as "cache" (getCacheDir()?).
Similarly, your app's main APK itself will be a bit larger, as it has to contain a chunk of code that knows how to load these dynamically-changing bits.
If you need to measure these values, either disable Instant Run, or run a release build (which automatically is non-Instant Run).
When I install my app on my main/new phone, the installed size is around 18.5MB
and when I install my app on an old Samsung Galaxy Ace (Mk1), for some reason, it installs with pretty much the same size, as you see here:
It runs perfectly on my main phone, but obviously, the old Galaxy Ace really struggles with it.
Now, I download a random game from the Play Store and with that one you can see the results here:
Much better, it takes up less space on the less capable phone than it does on the more capable phone.
However, my question is, where can I start to try to figure out why my app doesn't exhibit this desired behaviour?
Information about my project
I have provided 4 sets of Graphics within my project and they are:
Graphics
XHDPI: Total of 3.73MB
HDPI: Total of 2.87MB
MDPI: Total of 1.33MB
LDPI: Total of 1.03MB
Sound
OGG Sound Files: 202KB
MP3 Soundtrack: 5.6MB
The (Unsigned and signed) APK file is about 16.02MB
Apart from that there is a classes.dex file within the APK which is about 3.5MB.
In Eclipse, I link BaseGameUtils and Google-play-service-lib jar files.
I know that my game is slightly more resource hungry than the other game I downloaded - but that isn't the point of this question. I need to make sure that the size of the installed app is smaller on lesser capable phones than it is 'better' ones but as you can see, mine is exactly the same.
Any help would be appreciated.
Edit
Additional information if it helps:
The Samsung Galaxy Ace is running Android 2.3.4 Gingerbread
The other phone is running Android 4.4.2 Kit Kat
the answer is the picture.. you see android apps can specify locations where apps are supposed to be installed, whether internal or external- you can do that in your android manifest file
android:installLocation="auto"
Looking at your app you from the settings screenshot you have not specified that element in your manifest hence the "move_to_sdCard button" is inactive. Your apps installs in internal memory
coming to the other app, looking at the screenshot you will see that the "move_to_phone button" is active because they specified that feature hence since there wasn't enough space on your device it automatically installed your app on the internal-external memory or strictly external memory.. But when that feature is set not all resources or files are installed on the internal-external memory they are shared, so the size gets trimmed in the process hence that ouput.
Speaking about the lag of your app, you need to digg into your codes pretty much. also newer apis contain functions the old ones do not have, hence you need to re-evaluate the kinds of codes you choose..
Hope i am lucid enough
Probably the "Other App" is using the Multiple APK technique to publish the App on the Play Store. With this feature you can build and deploy several apk(s) each targeting a specific device density screen. In this way you can reduce the apk dimension since each apk will have only the resources for his target and automatically the Play Store will deliver the correct one.
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