I've a problem with my app relate to OutOfMemoryError and crash. I've realized two activity, first activity with a logo used to load application and a second activity with some buttons and a popup menù with some icons. Recently I've encountered problem with this popup menù that when is opened cause a crash with "OutOfMemoryError" warning. Before this crash I've used this menù without errors with only a single image repeated as test. When I've changed this image with different images it started to crash. I've added this android:largeHeap="true" to manifest too see if something changes and finally menu opens without crash but it lags when scrolling it. In application monitoring I've 112Mb used when menu is closed that goes to 204Mb when I open it. I've 115 images inside my drawable(mostly unused), about 35 active in my current Activity and additional 16 images when I open menu. Total images size is 4Mb, total used images size is 1Mb and total menu images size is 350Kb. I'm a newbie in Android but maybe I skip some conversion between png and memory in Android, but it's strange to me that 16 images(ImageButton) of 24kB with android:layout_width="85dp" android:layout_height="90dp" occupy so much memory and makes lag a new age smartphone. With this low sizes and no particular code(just xml files and some java to struct UI), how it's possible that I've this big numbers in my memory?
maybe you don't follow android standard size of icons, or the image is too large.
check this link for more info on how to use standard size in android : http://iconhandbook.co.uk/reference/chart/android/
Or you can use Universal Image Loader to display image see this link : https://github.com/nostra13/Android-Universal-Image-Loader
I have created an android project that has 3 xml files. Main Welcome and Temperature. When the app launches you click on a button in main to take you to welcome then a button in welcome to take you to temperature. Each xml file has a different background. but when I click the button in welcome to take me to temperature i get the out of memory error. this is discussed in this link.
why am I getting errors when I use different backgrounds in xml
I solved this issue when i realized my background images were too big. the screen size i was using was 1024X600 and the images i was using as my background were 1300X724. So i changed the sizes and the app worked however when i made more xml files with the same concept. different backgrounds but with the new size of image 1024X600 the further down the activities i got, the same error appeared.
So why do i get this error when i have change the images to match the screen size? and is there a certain size of image i must use? what does this error mean?
Actually I have for so long wish to know how to present graphics in a proper way.
In an activity, I have the following:
a background (png, full screen, 768*1280, 1.36MB)
3 icons (each icon has pressed and not pressed: 2 states, using 1 png 400 * 400, 300KB each), i.e. 3 icon * 2 pic * 300KB = 1.8MB
some more textviews
When the app starts off and directly goes to this activity, everything is ok, the activity can be presented properly.
Yet somehow when the app has run for some other activities, and then goes to this activity through a dialog box, then most of the time errors will occur, as follows:
Out of memory on a 15728656-byte allocation.
Question:
I have researched for sometime and some say to bitmap.recycle(), yet how to implement? through the onCreate? or actually 400*400 is too big?
If I want to change the background of an activity upon users' choice, i.e. when he presses button A, the background changes to bgdA, presses button B will change background to bgdB... in that way how that can be achieved?
Many thanks!
Depending on where your asset is stored is the amount of memory it might take, since scaling factor is calculated between the difference of densities, this is a little gray area because I haven't found any official android documentation that backs this info up, however I've seen that error so many times and this is the way I handle it.
1.- If you don't have the asset in the proper drawable-(density), this will cause problems because depending on the devices you are actually supporting, you should put the asset in drawable-xxhdpi or drawable-xhdpi, you will notice how the memory will decrease considerably
2.- If you don't want to mess with densities because it's a generic image which don't have much details(like a simple background), then add the asset in the drawable-nodpi folder, it will prevent android from trying to scale the asset it self..
3.- As good practice, try to create the asset with the proper size for the proper densities, 400 x 400 seems like too much for an icon, this will also prevent you from OOM, not only in this activity, but for other activities that might also need to load a good amount of assets, giving scalability to your app..
Always take on count that leaving the "resize" of an Image to the OS might cause huge amounts of memory allocated because the OS will try to resize it based on the formula width * height * 4bytes, the 4 byes are for ARGB of each pixel, 1 byte per color or alpha, so if your image is for example 1090 * 1920, it could easily become internally 8.3MBs even tho the actual image size is only a few KBs, and if it tries to scale it, it might double it's size too.
Hope this Helps
Regards!
Make sure you have a copy of your image for every drawable folder in you res, for example if you runnig your app on the S4 phone and you don't have all the images in the drawable-xxhdpi folder you will run out of memory even with reasonably small images.
Also if you need to change background at run time use setBackgroundResource.
Hope it helps
This is the common problem in android here is the proper solution
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
In easy words you have to scale the image down according to your requirement
I have a background png in my Android application. I would like to support lots of displays, but I have this one obstacle - many displays have many resolutions and many ratios. I would like to make sure my background is displayed properly and make it more ellegant, than just creating 10+ cropped png files in Photoshop.
My idea would be - a fairly large picture imported in the project. The app would find out screen dimensions and simply say starting points(x,y) and ending points, that would "crop" the picture and display it without any deformations.
Is there a way of doing it?
I think bitmap.createBitmap() is the method your looking after. The method simply lets you cut out a defined portion of the bitmap.
Images in apps come in many shapes or sizes, but to save space and editing time is there a way to use scaleable vector images?
Ideally I would have one vector image at middle resolution, I could then detect the screen size and scale the vector how I need and add the background using some custom gradients.
I'm using titanium for this.
Titanium doesn't yet support vector graphics, though it is available in native Android code via Shape Drawables. There is a third-party SVG library available for Android SDK.
For Titanium, branch the code based on the device screen size (Titanium.Platform.DisplayCaps), and find an image that works with decent performance on the device.
You can use PNGs with transparency and apply a background color to your view object.
I've found away round making different sized drawable:
Basically just one have folder called drawable within the res folder.
Make your artwork in what ever you use but make it large (at least 1080p for future devices).
Save the image's as PNG within the drawable folder but save them large. (IE at least 1000x1000)
Write a function that loads in the PNG but scales it (according to screen size & percentage of what size you want the drawable to be. So 20% of 800px width is 120px). I've managed to do this bit with 30ish lines of code, can't paste my code since I'm not on my working machine.
For me this has worked across all my apps for all devices, I've not had a single crash yet (1000's of installs, including Live Wallpapers).