I have one requirement to compress APK size based on type of device(LDPI, MDPI, HDPI.., etc). My client is demanding to give multiple APK's. According to his statement Small devices having low configuration so the apk size should be less, and MDPI is bit better than LDPI so the size may going to increase. So he is demanding to give the build accordingly. So that user will download the app with in less time and saves the internal/ External memory.
For that I tried lot of ways to compress the APK, but I failed at every aspect:
*9- Patch : My project does not contains all the images are 9-Patches, in fact 90% of images are non-9patch's.
*Pro-guard: I tried to reduce the file size using Proguard, but as far as I know proguard is for protecting the my code, and apk size is not much compressed.
* And I tried out not working out for me.
Right now I am following the bellow process, I know this is very bad procedure:
Generating the APK for LDPI devices I kept all resource files in res/ldpi folder only, I am following with same procedure for MDPI, HDPI, XHDPI Etc.,
By using current process, I'm wasting lot of time and it is very bad process also I guess.
To solve the above problem can you please help me out.
Use Gradle for Android and its support for APK density splits. Gradle for Android can then generate APK files for each density, plus an optional "fat APK" containing all densities. You can either use Android Studio as your IDE, or set up a build.gradle file that can build an existing project in the Eclipse/Ant classic directory structure.
However, your client needs to understand that not all distribution channels support distributing different APK files by screen density. The Play Store does. I do not know about other channels (e.g., Amazon AppStore for Android). And the user probably has no idea what the density of their device is, so relying upon the user to choose one of several versions to download from a Web site is unlikely to be reliable.
Inform your client that for all devices apk size will remain same. Make him/her understand that On play store you do not upload different apk's for different types of devices.
Related
Scenario:
I have an app with a lot of high res drawable images. I would like to deliver those assets with the build as opposed to via web/http/cdn.
Problem:
When uploading my .aab to google, I'm told that certain configurations will result in a build over the 150MB limit.
What I've tried:
I've extracted most of the large images to an install-time Dynamic Feature Module.
Using bundletool, I've simulated an xxxhdpi device on arm64 with two languages. The resulting base apks do not exceed 150MB. The Dynamic Feature Module apks ("packimages-*.apk") do, but as far as I can tell, that's not only ok, but that is Google's recommended way of reducing base apk size.
The limit on 150 MB is on the download size at installation time.
Since you mentioned that you configured the dynamic features to be "install-time", they will also be served at installation time and are thus counted towards the limit.
You may want to consider images that are needed at installation time (which you can leave in the base module) and images that can be downloaded at a later time (which you can put in an on-demand module) using the Play Core SDK.
I have an Android project with 3000 photo's that needs to be available offline. When I include all the photo's in the build, the build fails. When I remove some of them, the build succeeds.
I have put the photo's in two dynamic modules that download at install time.
Here is the gradle scan for reference: https://scans.gradle.com/s/nn6eo527qvge6
Is this purely a size issue and if so, how do I get around that?
Is this purely a size issue
Probably.
how do I get around that?
Start by moving your photos out of res/drawable-xxhdpi-v4/ and into assets/ and adjust your code that consumes the photos to match.
Then, see what the resulting APK size is and compare it with the size limits for your intended app distribution channel (e.g., 100MB limit for the Play Store). If you exceed that limit, you will need to work through alternative approaches (e.g., APK expansion files).
To expand on CommonsWare's answer, I think the way you should do this is not by using Dynamic Modules but by using asset delivery. It's kinda "marketed" as a "for games" thing, but it's not limited at all by that.
The idea behind asset-delivery is that you have a pack of assets (images in your case) that you need for your app to function.
This "pack" of assets can be requested at install time, or later "on demand". All this is confusing because Dynamic Delivery sounds very similar. However, as stated at the top of the asset-delivery page, they use Different APIs.
In all honestly, I haven't used Asset Delivery, so take it with a grain of salt, and keep the considerations at hand, for example (and I quote):
If the download is larger than 150 MB and the user is not on Wi-Fi, the download does not start until the user explicitly gives their consent to proceed with the download using a mobile data connection. Similarly, if the download is large and the user loses Wi-Fi, the download is paused and explicit consent is required to proceed using a mobile data connection.
I am getting duplicate files in my source code:
This happens quite often with Android Studio and it happens will all types of files, not just gradle files. It typically happens when I checkout a new branch or swith branches.
What is causing this and how can I prevent it?
As a note, this question was originally posted with image files, thus the image answers. However, this is not limited to image files and I understand why there are multiple image files for different screen densities. I have updated to reflect that there are other files being duplicated.
Do you have a Mac, and is your project stored in your "Documents" directory?
Filenames that include " 2" are generated by iCloud when it can't reconcile two versions of a file. E.g. if you have two computers, and both of them share their "Documents" directories via iCloud, and a file were to be changed simultaneously on both computers, iCloud would wind up creating e.g. a build 2.gradle file.
I found this was happening to me, even though I'm only using one computer to do my work. I suspect that Android Studio may be interacting with iCloud directly, not realizing that it's working on files that are already backed up on iCloud. (See Android Studio generating hundreds of duplicate " 2" files).
I seem to have fixed it by moving my project directory out of Documents. At any rate, I haven't had a problem since I did that.
(Credit to Mike M. for noticing the similarity between our problems.)
Since different devices support different screen densities, all non-vector image drawables should have an image asset for each type of density. So, from a development standpoint, you're using the same Drawable but the app will use the correct image size based on the screen density of the device the app is installed in. I suggest you take a look at this article for more information.
It's ok. Follow the every folder. Folder name is different according to possible phone size Different phone size is different, that’s why they support different size images.
I'm trying to get the Unity mobile Android APK build size to below 150mb, but it's currently at 170mb. I'm reading through many online docs, but can't find anything that so far reduced my build size. (For reference, I'm creating a "Virtual OS" where many virtual apps are bundled into one, and can be experienced in many different environments, so that increases size.)
My main question is, how can I find the biggest file size "offenders" in my project? Unity's doc tells me to look into the Editor Log's Build Report list, but the files mentioned in the top there (as "uncompressed", e.g. my 20k something PNG becomes a 1+mb file in that list), mainly textures, do not actually help when I next time remove them in another test build. Neither does it relevantly help when I change the Android texture setting to something more highly compressed (e.g. 1024 max Mitchell, which I had for most of my files anyway).
I've tried both APK building, as well as ABB, but both results are quite big. (Switching the API Compatibility Level from .NET 4x to 2 doesn't help either.) I'm compiling to 64bit architecture.
Edit: A first big improvement became removing an (unneeded for Android) Oculus directory (and accompanying Package Manager packages). But this wasn't shown in any charts.
Thanks for any pointers!
Is it possible to split my Android apk of 512MB into different parts or modules.
Compile small part of it into a release Apk (small Apk size) for Play Store.
Then fetch the remaining parts or modules from online or your own server during first time install on a device.
Thats:
Small Apk to Google Play Store
Fetch remaining big files after first install.
I am using Android Studio.
Of course you can, that can be easily achieved if you got to split heavy resources(like images, videos, databases). Here you must write some logic which will download that resources and will work with them after a successful download.
I cant imagine a situation when you must to split a code in a separate module, compiled code is light and dont increase apk size so much as another resources. Code can become heavy when there is a lot of code from libraries, in that case I suggest you to learn about Proguard Shrink.
Also you can learn why in android is not possible to load java modules in runtime. On of the reasons is performance given by JIT
Here a is workaround with ndk How do I import shared object libraries at runtime in Android?