Need to build an android apk less than 20kb, and rest of the contents in the app should download dynamically, does anyone have idea about that.
If i create a simple android app and build it without any source code, it results in 3 MB atleast.
So, so pls someone suggest me how can we create an apk in kb.
I decided this would be a fun challenge, and was able to make a tiny app (no real functionality) that was 16kb. You can find the source code here. It would have been even smaller with only ldpi assets.
Some caveats:
Don't expect an app with any real functionality to come in this small. Keep in mind that 20kb is around 20,000 characters worth of data, which would be about the length of a very short story. 20kb really isn't realistic, and you are going to end up taking up that extra space on your user's phone when you download the "rest of the app" later anyway.
My example has only mdpi assets. Things like launcher icons have to be bundled with your application, so either your icon will look awful on large devices, or you need to modify your requirements.
Some tips:
Enable proguard. Both minification and obfuscation. The latter is a hyper-optimization, but when you are trying to go that small, every bit helps.
Take out any libraries that aren't absolutely mission critical. You aren't going to make it with any of the support library.
Support only the lowest resolution screens you can. ldpi assets will look bad on high density screens, but are exponentially smaller than mdpi, which is exponentially smaller than hdpi, etc. Resources are almost guaranteed to be the largest piece of the app.
Read all of the Shrink Your Code documentation. One great tip if you are using any libraries that provide resources is to use resConfigs to strip out any languages, densities, and native ABIs that you don't need.
Android Studio 3.0 has an "analyze APK" feature that will break down what pieces of the APK are taking up the most space- use that to identify your targets for cutting down the size.
Related
I saw many questions like these and read many docs, but I'm still not sure what is the proper way. I have application with 500 photos, and first how I was doing it was to scale every photo 5 times, to the pixel sizes for each ldpi, mdpi, hdpi, xhdpi and xxhdpi. But, after doing this, application got much bigger than it should have and since you can only upload .apk with 50MB to market, I found myself in trap.
I found several options which can be made here, but not sure which is the proper one:
Make a multiple layouts for each of this densities on devices and scale with different dp's in them
Make multiple .apk files, each for every device with different densities (still, Google is making accent on this option to make it only if you really can't make it anyhow else - why is that? this would be perfect for me, since I already have photos prepared for each density)
Make multiple pictures and put it just in one .apk - this can't work for me, since the .apk is too big
Make pictures which are good for MDPI device, put them in "drawable" and they will automatically resize bigger for other devices and smaller for smaller density devices - this makes problem since pictures, when they're being resized from MDPI to other bigger dpi devices, pictures are blurry.
So, anyways, proper way of handling this would be to follow first option, am I right? I should just take xxhdpi pictures (so they're always scaled from the best picture), put them into drawable-nodpi? However, I have some problems with scaling on ImageButtons.
Please, tell me how to make it properly.
My practice is using only one apk to keep the app simple and easy to develop and publish.
Use only one drawable, the high the better. it depends the final apk size you(market) can bear.
May be this question will help:
Only use XHDPI drawables in Android app?
An addition to the Loki's answer. You could resolve the poor perfomance on small scale devices making a cache folder for images. Downsize the image the first time the device loads it, according to the density of the device, save it to the cache folder, and the next time use the cached image.
Bonus if you make this in an batch process in the background!
I don't know but could this be done as an update to the app. You download a plain vanilla app that prompts the user to upgrade, or just does it automatically.sounds like something Google needs to improve on. When I download an app I only need one app for one language one device.sounds like Microsoft mentality
I was doing a little project thing for my school...
I made a simple calculator app...with simple mathematics operations...
And when the apk file is created and installed, it was consuming the memory space of more than 700 kb in the phone.
While in the android market(play store), there are just similar apps which are of low sizes and are taking memory space of less than 500. I was creating app in eclipse...
Will somebody plz help me out with this that how they do make apps of simple lower size.??
The smallest APK I created is ~35kB. Size increases dramatically with the included assets. Check the size of your /res, /assets and, if you have it, /raw folders. The APK size will be larger than those three combined. Further, any included lib counts, and adds bulk, even (and especially) the compatibility library, if you use it.
If you're having lot of graphic assets, then you should probably look at using 9-patches. They save a lot of memory.
Please elaborate your question. When you say memory, are you referring to the RAM OR the actual storage memory ?
If you are referring to storage memory...
The storage memory depends on how big your application is. For e.g. IF you have too many images of large size, then app size will increase.
By the way, 700K is not really too much. You are OK.
I've read this question but am still uncertain of the value of different DPI targets.
Doesn't supporting multiple density images add to the .apk file size, whereas just using high-res images offers a solution for all screens (using automatic scaling)? There's still only one binary for users to install unless one limits the app to phones and tablets, so the smaller the file, the better.
Is downscaling of images dependent on hardware implementation and sometimes messy nearest-neighbour resampling is used, or can I be confident it'll be a bilinear resampling no matter the hardware, which is fine for photos? And is there a significant performance gain in providing suitably presized bitmaps?
It seems to me that the extra meg or two of asset files may be more cost than gain.
I was toying with the same thing myself. Eclipse makes it easy to add every resolution as you can simply add an Android Icon Set which automatically creates the right sizes for you, it makes the app a bit bigger. Apparently XHDPI is only supported from Froyo (API 8) so if you're going to support before that you need to include HDPI. Also older devices, the rescaling doesn't look as nice and it's slower but the new devices, there's no real difference. At the Google IO I recall them saying it's okay just to use the XHDPI if you're targeting at and above API 8.
I had an android app built especially for medium screen size android devices.
Now it was required to build that same app for a device called nook-color (by Barnes & Noble)
So for this we made all the images bigger & size & changed the layouts.
The result is that the apk which was 97.5 Mb earlier has now become 124 Mb in size.
Now the testers have complained that the application has become slower and it takes a little longer for any screen to open up. I am wondering whether this is due to bigger images or there is something else.
Can you please tell me what could be the reason for this.
124 Mb for an app seems to be a little bit excessive. I'd suggest trying to scale down the image assets, use Nine Patch images, as well as using PNGCrush
Yes. The delays are (at least in part) due to loading larger images (de-compressing them to bitmaps, to be more exact). Unless you can't help it, you should attempt to convert as many of these images to 9-patches : http://developer.android.com/guide/developing/tools/draw9patch.html.
I've been through this post (and others) as well as through the documentation about supporting different screen resolutions in Android, but I couldn't find a clear answer to a (simple) question:
Is it ok to just use "res/drawable" for images in an android app?
Background: The only images that are needed in this specific app are the app icon itself and an icon for a notification, there won't be any images in any layout.So in my understanding, if no "hdpi"-, "mdpi"- and "ldpi"-folders are found, Android will use "res/drawable" as the fallback.As the only pitfall with different screen-resolution seems to be that Android will scale images for a specific resolution if no special one is found, this should only be a problem when UPscaling, because the image will get blurry. But if I provide all "hdpi"-images in "res/drawable" (instead of 3 different ones), won't Android just DOWNscale those images if the size is too big?If that's true, I could save some APK-space by just a third of the images.
Follow-Up question: I read that for API-level 3 a dir by the name "drawable-v3" is required. Is that true or is "drawable" the fallback for this API-level also?
Any hint is appreciated.
The images in the drawables folder are assumed to be at mdpi resolution, so they will get scaled up/down if you don't provide the others.
Scaled up images will be low-resolution and look fuzzy. Scaled down images will have pixels missing and look jaggy.
So your app will "work" with only one set of default images, but will look awful on many devices. I strongly advise that you create the images in different sizes, so it looks great on all devices - it's a bit boring, but not hard to do.
It won't be long before we have xhdpi devices, so while you're at it you may want to create those too.
I assume you've read this
Not a complete answer, but: highly downscaled images can and usually do look just as bad as upscaled images (but in a different way), because graphics libraries almost exclusively use interpolation methods for resizing, and interpolation methods are limited in terms of how much they can shrink an image before serious information loss (to about 50% for linear methods and down to about 25% for bicubic methods). This is why most platforms have evolved conventions (like hdpi, mdpi etc.) that let you embed images that are best for each screen size.
I use drawable/ all the time, and then I go to BestBuy and all the local wireless stores and test my apps on small/large/huge(tablet) devices and they look just fine.
Unless you have some reason to target pre-Donut devices (now only 4% of the devices according to http://developer.android.com/resources/dashboard/platform-versions.html), then you should put your bitmaps in one of the -Xdpi directories. The generic "drawable" directory is a synonym of "drawable-mdpi" for compatibility reasons, but a modern well-written app should be putting its drawables in a directory matching the density they are designed for.
res/drawable is the fallback
the caveat is that scaling not only degrades the image but takes processing time too.
I have not even read the API-Level 3 docs yet, sorry for 1/2 an answer
For what it is worth I found the image handling of Android to be tedious and unreliable. The concept of including different size images for different screens will result in large application files bloated with images. There are already screens that don't fit in the standard resolution ranges. I have found it is best not to let android handle the scaling, it seems to create a base image for the smallest screen you target and then scale it up resulting in ordinary looking images on large screens. This happens even if you made the image specifically for the large screen.
My solution that seems to work on everything from a 2" samsung phone to a Sony Tablet is to create images at high resolution and use Bitmap.createScaledBitmap() to get the size I need.
caveat: I am new to Android and have lots to learn.