I'm developing an Android app which supports the following densities: ldpi, mdpi, hdpi and xhdpi. I have my images stored in each folder and scaled up according to the density. My problem is my APK size is about 100 MB, I guess the images of the four resource folders are adding up.
Is there any way to reduce this APK file size? When I tried to upload my app for testing in-app billing, Google Play has a limit of a 50 MB APK, so can't upload.
Why do users need to download APK which has images that they will never use from another resource foler? Any idea?
Why don't you use expansion file? Or try to compress data.
In September 2015 the maximum limit on the Play Store has been increased to 100 MB, if you need more space you can add up to two 2 GB expansion files but it's a bit tricky to implement.
Starting July 2016, when you upload an app, Google Play downloads only the part of the APK which has changed, reducing data consumption.
If you think that your problem is caused by the resources, why not to check the size of the drawable-<density> folders, just to have the exact idea of how much space every density is taking?
In any case, if you include only the low-resolution resources, on high-resolution devices they will be scaled up appearing blurry, while if you include only high-resolution resources, they will be scaled down on low-resolution devices, increasing the risk of OutOfMemoryErrors at runtime. In your case a good approach can be to include only the mdpi and xhdpi resouces: ldpi will then be scaled from mdpi, and hdpi from xhdpi.
Also check if you can replace some of your resources with 9-patches or, even better, with SVGs.
The last solution is to provide different APK for different densities (and screen sizes), as documented here.
Related
During Development I was importing images for different screen sizes like mdpi, hdpi, xxhdpi, xxxhdpi etc.
I had to give image a fixed sized like 240dp x 80dp. then what is the role of importing images of different screen size if I am giving fixed value. it is better if I will import one image with good resolution then use fixed value.
please clear my concept if I am wrong
When user with mdpi device screen starts your program - program will get images from mdpi folder of resources. If you have only xhdpi images - on his mdpi device system will downscale image from xhdpi folder 2 times before showing. If image exist only in mdpi folder - on xhdpi device image will upscale 2 times before showing. Downscaling/upscaling means extra CPU, memory usage and lower performance. When you provide image for all densities system will just show proper image without extra calculations. Check scale coeficients here and link to docs
If you provide image for all densities there is also profit in .apk size for user. When you upload .aab file (Android App Bundle) to google play (instead of .apk) and user installs your app he will download .apk file which contains images only for his density (image copies for other denseties will be removed from apk). It means that apk files for mdpi users will be much smaller than .apk files for xxhdpi users.
I am trying to reduce my apk size. Currently it is 7 Mb after using Proguard. It's a very huge size for a small app. So can I remove mdpi and xxhdpi images from /drawable?
Use folllowing property of proguard
minifyEnabled true
shrinkResources true
You can reduce PNG file sizes without losing image quality using tools like pngcrush, pngquant, or zopflipng. All of these tools can reduce PNG file size while preserving image quality.
There are also more tricks and methods For More info in Details Read the Official Documentation of Android Developer
Quoting from Reduce apk size|Android Developers
If you know that only a small percentage of your users have devices with specific densities, consider whether you need to bundle those densities into your app. If you don't include resources for a specific screen density, Android automatically scales existing resources originally designed for other screen densities.
You can remove mdpi drawables if you are sure enough that most of your user don't use devices which supports mdpi drawables.
In case of xxhdpi the page Reduce apk size|Android Developers suggests
We recommend that every app include at least an xxhdpi image variant.
So you should keep xxhdpi according to this.
I've read "Supporting Multiple Screens" on the official docs.
I have around 15 activities. I currently have 4 background images. I've randomly assigned a background image to each of the screens in simple XML.
All these images are around 400X800 in the drawable hdpi folder.
Now the problem:
My app looks bad on tablets. The low resolution images are stretched out.. making them very blurry. So, I'm thinking about adding some higher res images.
The question:
So, now I have 4 images in the hdpi folder. (read slowly) ... If I add the same images of higher resolution in the xhdpi folder .... Will a device with screen of hdpi resolution also have to save the other res pics ?
I know that was confusing, below I explain with an example:
Okay, so I have three devices..
One small,
One medium,
One Tablet.
Now I have 3 sets of images in the mdpi, hdpi and xxhdpi.... for each of these.
Now, will the small device's apk file also contain the bigger images which are not used in it? ... I mean, can android choose which images it wants to download (changing the app size for different devices) ...?
Or does it simply download everything (increasing the app size)... and choose later on while running ?
The thing is, my app is like 800kb .... and adding 3-4 background images for large phones or tablets will drive up the app size to 5-6 mb... That's what I don't want.
So, are all the things stuffed in the apk downloaded equally on all phone sizes ? or are the pics downloaded selectively?
Do small phones unnecessarily download the big images too ?(vice-versa for tablets ?)
(I asked this question, because in many android apps , their size says "Variable for different devices" or something like that... and there's no mention of this whatsover, anywhere on the internet. Trust me, I googled for an hour.)
Yes. Your project size will increases whatever images added in all folders. If you are designing for 4 different screen your apk size will increase automatically. If you want any images common for all screens, then you can create a drawable folder and place the image in it. So it will pick automatically. Both apk size and your project quality are important. So you should consider image size when adding to the project. By using padding and other xml factors you can adjust screen size by same image also.
The whole apk is downloaded together with all images for all resolutions. As you usually upload only one file to Google Play, the same file is downloaded by everyone.
There is an option do distribute different apk files based on device onfiguration but it is not very convenient to manage.
You can read about publishing multiple apk in here: http://developer.android.com/google/play/publishing/multiple-apks.html
I've used the following as my research :
http://developer.android.com/guide/practices/screens_support.html
Too large APK due to multiple densities and screens sizes?
How to reduce App (.apk) Size
I'm currently working on getting my application to support multiple screen sizes. At the moment I don't have the following in place:
Separate layout files for different screen sizes
Separate images in the relevant image-density folders (ldpi, mdpi, hdpi, xhdpi).
Other info:
All images are .png
I do want to support large screen sizes like tablets
I do not wish to support anything below this size - 320x480
Even though I don't have everything in place yet, my app is highly customized(in terms of graphics) - and is now a little over 4 mb.(.apk size)
If I do add separate layout files, and images - the app .apk file size will probably explode.
Question:
How can I get around this and keep the .apk file size to a minimum?
Idea's I've come up with so far:
Bitmap sampling - and creating an image loader
Downloading images from the net - I wish to avoid doing this unless there's no other option.
Converting some files to .jpeg files - Still a little unclear on how that works.
Using .9.patch image files? I believe this makes layout design easier.. but not sure if I could use that to save on .apk size
You can enable ProGuard in release mode. The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer.
http://developer.android.com/tools/help/proguard.html.
Also have a look at the video in the link
http://www.youtube.com/watch?v=amZM8oZBgfk. The talk is about multiversioning.
Tips for reducing .apk file size
http://developer.sonymobile.com/2012/01/31/tips-for-reducing-apk-file-size/
I'm writing a program about letters for babies and I'm using 28 images. It's a flashcard program, and was running ok until I reached 20 images.
It force-closes before opening. I'm still in my early stage in the program. I put my images in the drawable-mdpi. After working on this error for 2 days, I discovered that when I split the images between drawable-mdpi and drawable-hdpi it works well, but the images that are in the hdpi folder are smaller, although they are of the same size.
I want to know, why does it work when splitting the images? Is there a limit to the number of images per folder? And also, why do images that are in the hdpi folder get smaller in the app?
There is no limit of the number of images per folder. I have an application with more than 360 pictures in the folder drawable-mdpi (really) for a total size of 32Mb and it works well.
If you test your application on a mdpi screen (160dpi), and you had hdpi images (for 240dpi), then the application automatically reduces them at run time by multiplying their size by a factor 160/240 = 0.66, which explains why they appear smaller.
See Multiple screen support for Android for more information.
The dpi are the "Dots Per Inch", Android allows a simple way to ensure that the Device running the application will load the best available resources, for its "bucket", the category of dpi it uses.
You can disable this behavior, by creating another drawable folder (such as res\drawable-nodpi), and place your bitmaps there, and then loading then, and doing any mutation as needed.