I recently rebuilt my Android project to target 2.2 from 2.1.
In the old project, I did not specify a target SDK (the manifest did not contain something like: android:minSdkVersion="8"). This gave me an error in the console when running, but everything worked fine so I didn't fool with it.
The new project now uses android:minSdkVersion="8" in the manifest.
But now my drawables from the /drawable-nodpi/ folder are loading with scaling, making them much smaller and significantly changing the desired visuals.
If I cut out the tag from my manifest, they load properly without scaling.
Even when loading my images like so:
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inScaled = false;
Bitmap bm = BitmapFactory.decodeResource(_resources, resId, opts);
They are still scaled when I declare the minimum SDK in the manifest, but not scaled if I remove that tag.
Why is this happening? How can I load them without scaling while still declaring the minimum SDK?
Did you try this?
From Google:
If you plan on reading an image as a
bit stream in order to convert it to a
bitmap, put your images in the
res/raw/ folder instead, where they
will not be optimized.
Related
I load an image from resource folder via:
bmp = BitmapFactory.decodeResource(getResources(), R.drawable.imagename);
It works for regular images, but if I try with a large file (2100*1600), it would not show. In the debugger, I can see the picture in the "bmp" variable but it does not show on the device nor does it give any error message. But if I move the source file to the drawable-xxhdpi folder - then it shows properly. So far so good. However when the user selects a custom image from his pictures, larger images still do not work. I load from the pictures folder via:
bmp = MediaStore.Images.Media.getBitmap(this.getContentResolver(), selectedImage);
The drawable-xxhdpi workaround does not apply here. Can anyone point me in the right direction?
What fixed it for me was to add
android:hardwareAccelerated = "false"
to the application tag in the AndroidManifest.xml. Apparently the API tries to load the image as texture to OpenGL – or something like that.
Now the app is slow, but at least everything works.
What's the best image file format for Android in terms of memory? PNG is recommended for iOS as xCode does some magic with it.. Is it the same for Android?
I'm currently developing a big app with multiple animations going on (sliding in screens, fading etc etc). All works well so far! However I have noticed the view animation where the view contains an ImageView with a (quite large) PNG as the source is a bit laggy.
Obviously I can make the PNG smaller, but is there anything extra I can do to reduce the amount of memory the ImageView takes up/makes the animation smooth? I know PNG has a much larger file size than JPEG, but I can't see this being a problem, the JPEG or PNG (I assume) is eventually stored as an array of colours, so they would both take up the same memory. PNG is probably better for loading due to less cycles uncompressing. Again I only assume, my knowledge of image file formats is null.
Alternatively is there anything else causing the lag? Is the bitmap scaled to fit the view each onDraw() during the animation so should I scale the bitmap in code before giving it to the ImageView?
Thanks,
The formats supported by Android are: PNG, JPG and GIF (also 9.png).
The recomendated is PNG as said in dev guide
All of them are stored in memory as a Bitmap, so the most important thing is the color deph, like this:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.icon, options);
More info: stackoverflow
and add (after honeycomb):
<application
android:largeHeap="true"
...
to your manifest file :=)
thanks to my dear friend :)
I am working with a team on an Android game. There was a graphics spritesheet resource that was created with an initial tile width of 96 pixels and later reduced to 64 pixels. On the author's computer the project runs correctly at the new dimensions but on my machine, even though the image has been updated to the new resolution, when I go into debug and call getHeight() on the BMP resource, it returns 96 and the animation displays incorrectly (gets clipped).
I have tried:
refreshing eclipse filesystem
re-cloning the project and creating a clean project in eclipse
starting eclipse with -clean
cleaning the build
The problem persists and I have run out of ideas. Please, how do I get get eclipse to uncache whatever crud its keeping somewhere and use the new image that's plainly sitting in the /res/ folder??
I am testing the project on the emulator. Running android api 2.1, level 7.
Bitmap bmp;
bmp = BitmapFactory.decodeResource(getResources(), R.drawable.blah);
You need to set the "inScaled" flag when loading the Bitmap if you want to force the original size. I found this out the hard way when my Open GL textures weren't showing up on larger screen devices.
Something like this should do it:
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inScaled = false;
Bitmap bmp = BitmapFactory.decodeResource(getResources(),
R.drawable.my_image, opts);
Android automatically scales images in the resources folder for the screen resolution of the device. So even if the source image has a height of 64 pixels, there's no guarantee the .getHeight() will return 64.
Moral of the story: don't hard-code values for the sizes of images - use the accessor methods.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Android app loading images from /drawables-nodpi/ with scaling
I recently rebuilt my Android project to target 2.2 from 2.1.
In the old project, I did not specify a target SDK (the manifest did not contain something like: android:minSdkVersion="8"). This gave me an error in the console when running, but everything worked fine so I didn't fool with it.
The new project now uses android:minSdkVersion="8" in the manifest.
But now my drawables from the /drawable-nodpi/ folder are loading with scaling, making them much smaller and significantly changing the desired visuals.
If I cut out the tag from my manifest, they load properly without scaling.
Even when loading my images like so:
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inScaled = false;
Bitmap bm = BitmapFactory.decodeResource(_resources, resId, opts);
They are still scaled when I declare the minimum SDK in the manifest, but not scaled if I remove that tag.
Why is this happening? How can I load them without scaling while still declaring the minimum SDK?
There is another explanation given here:
"If you don't specify <supports-screens> or minSdk, then your app will run in compatibility mode, meaning that it's given an HVGA (240x320) "virtual screen", which is then scaled as a whole. So your images will be scaled."
The original poster was therefore running their app in this compatibility mode before and the images were automatically scaled up from HVGA to the actual screen resolution; by adding minSdkVersion the images were no longer scaled and therefore appeared smaller.
When you set minsdkversion you are telling Android that the app can work from API level 8, which is Android 2.2. Previously since you didn't specify that, Android knew how to handle assets, but now with minsdkversion line in manifest you are providing guidelines.
Read up on how all assets and assets hierarchy is implemented in Android here and here. This may be not the quick fix answer you want, but it will help you understand Android platform better.
I know this is an ancient question and the answer probably means little to you today, but because I just wrestled with this for a day and a half, I figured I'd throw out the answer for anyone else.
No matter what I did my images would be loaded from resources with a strange scale. I tried all manner of methods, from using Options.inScaled=false to setting inDensity = 160, to even using an InputStream and decoding the bitmap from the stream. Nothing worked... Images that have a raw size of 340x480 always loaded with some weird dimensions like 321x481 no matter what.
I went to look at the source image itself and see what dpi/ppi it was saved at. The image was created at the correct dimensions but its internal ppi was 72. I changed the image to render at 160ppi (which blew up the dimensions) and then scaled the dimensions back down to their origial pixels. Using this new source image, at a 160ppi that matched the 160dpi of the display, it rendered just as expected without any weird scaling.
So remember, if your source images are not intended to scale at all, you should make sure either they are set at a ppi that matches your density or that when you decode the bitmap from the bitmapfactory that the options specifies the ppi that the image itself was created to fill.
I created a background .png for my application in GIMP. It's resolution is 640x480, which from googling, seems to be the resolution for a default emulator. My problem is when I apply the background to the RelativeLayout with android:background=#drawable/bg and run it, there are lots of artifacts in the image. As if the emulator could not provide enough colors to display the .png correctly. What is going on here?
P.S. This image is nothing to fancy, just simple lines and radial gradients.
It's resolution is 640x480, which from
googling, seems to be the resolution
for a default emulator
640x480 is not even an officially-supported resolution in Android, let alone a "default" one. Here is the list of supported resolutions.
Also, you want to watch your color depth. I forget the details, but not everything can necessarily handle 24-bit color, due to LCD limitations.
i've gathered 3 possible solutions:
for each problematic image that you have, create and use a bitmap drawable in the xml.
the disadvantage is that you create multiple files. i've tested the other special flags (including the code changes), and haven't noticed any difference.
res/drawable/image_file.xml
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
android:src="#drawable/problematic_image" />
put the problematic image in the drawable-nodpi folder. the disadvantage is that it will use more RAM this way, as it doesn't downscale according to the density. a similar approach can be done in code:
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inDensity = 1;
options.inSampleSize = 1;
options.inTargetDensity = 1;
options.inJustDecodeBounds = false;
final Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.problematic_image, options);
imageView.setImageBitmap(bitmap);
if the file is a png file, take a pixel that is least noticable (for example the bottom-left), and change its opacity to 254 instead of 255.
the disadvantage of this method is that it makes the image to take more space , and change the image itself.
all methods worked on galaxy s and galaxy s2 , with android 2.3.x .