There is an app which I want to adopt to xhdpi resolution phones. So I made resources for that resolution and all went fine regarding the xhdpi phones.
I have a test mobile phone which is normal hdpi and the layout is now messed up (after I made fixes for xhdpi phones.
The layout structure looks like this:
/res/drawable-hdpi
/res/drawable-normal-xhdpi
/res/layout
/res/layout-normal-xhdpi
When I load the app on normal hdpi phone, I see that it uses layout from /res/layout-normal-xhdpi and images from /res/drawable-normal-xhdpi.
Shouldn't it use resources from the lower resource folder like /res/layout and /res/drawable-hdpi? It does not and I do not know why.
According to How Android Finds the Best-matching Resource system eliminates resource files that contradict the device configuration, but it looks like your case is expected, because of this exception:
Exception: Screen pixel density is the one qualifier that is not eliminated due to a contradiction.
This way a device of normal hdpi configuration matches to /res/drawable-normal-xhdpi.
Related
I have a default layout\ folder for all my layouts and layout-hdpi\ for just one that is not displaying properly on lower resolutions. Problem is that my emulator with xxxhdpi and xxhdpi (haven't checked xhdpi) is accesing layout.xml from wrong folder layout-hdpi\. Why and how to fix it (besides creating layout-xxxhdpi\ and layout-xxhdpi\ for the same file)!?
That's a very interesting behaviour, but as the documentation describes:
Note: Using a density qualifier doesn't imply that the resources are only for screens of that density. If you don't provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match.
And if you look a little bit further onto the chapter How Android finds the best-matching resource you will find the following:
Exception: Screen pixel density is the one qualifier that is not eliminated due to a contradiction. Even though the screen density of the device is hdpi, drawable-port-ldpi/ isn't eliminated because every screen density is considered to be a match at this point. More information is available in the Supporting Multiple Screens document.
I created an app with images, and I added them via Android Icon Set wizard. The wizard created 3 versions for the images - mdpi, hdpi, xhdpi.
I published my app on google play, and I got a crash reports from users that have ldpi screen. The exception was Caused by: android.content.res.Resources$NotFoundException: File from drawable resource ID #0x7f02007f.
The drawable was exists in mdpi, hdpi and xhdpi and the app worked to the rest of the users.
So I guess that the problem was that the drawable dose not exists in its ldpi version.
So my questions are:
1) Is there any way to say to the app to auto scale the mdpi drawables instead of crashing?
2) For support ldpi screens, must I edit the images to ldpi size?
Thanks.
This is a common error of different densities management, so these are the answers to your questions.
1.- No, in the way your assets are stored but Yes, "ONLY if your asset is in a lower hierarchy of your current density" for example: If you have assets in drawable(default non specific density) and drawable-ldpi AND you run the app in a Medium Density Device, the OS will try to resize your Images from -ldpi to your density (if using dps in the Image but will cost memory). The way the OS handles the Assets is the following:
Lets say you have:
res-
-drawable
-icon.png
-drawable-ldpi
-icon.png
-drawable-mdpi
-icon.png
If you are running an app in a HIGH Density device the OS first will try to find your asset in drawable-hdpi, but since it doesn't exist it will start going down the hierarchy until it finds it, so in this case it will not find it in drawable-hdpi but will find it in drawable-mdpi and will use that one to populate, everything will be fine but will cost in memory the difference of densities in the assets.
Now the exact error you have comes to play when the OS goes down the assets folder hierarchy and goes until the end and do not find anything for example:
Lets say you have:
res-
-drawable-hdpi
-icon.png
If you run this app, in HIGH Desnity Device it will run perfect, because will find the asset in the first try and will never go down the hierarchy, same case for Extra High Density Device because if it doesnt find it in drawable-xhdpi it will find it in the next step when going down the hierarchy to drawable-hdpi and will work just fine, but for MEDIUM Density, however, first it will try to find it in drawable-mdpi since its not there, will go down and try to find it in drawable-ldpi no luck either so it will go to the "default (drawable)" which is a good practice to contain all the assets in an average size to at least make the app look blurry than crashing, since the OS will not find the Asset either BOOOM no resource found, there you have your exception, this mechanism applies for pretty much any resource in Android
2.- YES, you must create your assets in ldpi and store them either in drawable-ldpi or drawable(default - no density) in order to make it look good.
All this information has been taken out of a book and if you still have doubts, create an empty Android Project in Eclipse and notice how the SDK creates one icon_launcher.png img in each density with a specific size to handle exactly this issue. As a recommendation in my experience I've found useful to always take care of all the densities, but more important having all my assets with an average density/quality in the default folder to avoid this exact issue in case you could forget one density during development, is better a blurry asset than a crash.
Hope this Helps.
Regards!
Is there any way to say to the app to auto scale the mdpi drawables instead of crashing?
This happens automatically, unless the maker of the firmware (device manufacturer or ROM modder) screwed it up.
For support ldpi screens, must I edit the images to ldpi size?
No.
I would look up 7f02007f in the R.java associated with your production code base and make sure that it is what you think it is. Bear in mind that these numbers get regenerated on every compile. Perhaps this is a case where there simply is no drawable resource for this number, in any density, because R.java was out of sync with the actual resource packaging. To avoid this problem, do a clean build (e.g., Project > Clean inside of Eclipse) as part of making the production APK.
I was checking my bug reports and from time to time we get this bug report from our app.
I can't pint point what is the actual problem.
This resource does exist, most of devices work fine but some specific devices like LG-E510 or U8815 just cant load this resource.
Any ideas?
android.content.res.Resources$NotFoundException: File res/drawable-xhdpi/action_bar_search_icon.png from drawable resource ID #0x7f02007f
at android.content.res.Resources.loadDrawable(Resources.java:1714)
at android.content.res.Resources.getDrawable(Resources.java:581)
at com.actionbarsherlock.internal.view.menu.MenuItemImpl.getIcon(MenuItemImpl.java:384)
at com.actionbarsherlock.internal.view.menu.ActionMenuItemView.initialize(ActionMenuItemView.java:128)
at com.actionbarsherlock.internal.view.menu.ActionMenuPresenter.bindItemView(ActionMenuPresenter.java:192)
at com.actionbarsherlock.internal.view.menu.BaseMenuPresenter.getItemView(BaseMenuPresenter.java:176)
at com.actionbarsherlock.internal.view.menu.ActionMenuPresenter.getItemView(ActionMenuPresenter.java:178)
As you have stated, if the phone / tab accesses the xhdpi directory then we expect it to scale the image appropriately to fit the screen. Therefore we expect that if the resource exists in ANY ONE of the directories then we will never see a ResourceNotFound exception. HOWEVER:
xhdpi was only introduced in Android SDK 8, so if you target SDK 7 and earlier you may run into problems:
Only use XHDPI drawables in Android app?
Another reason why Android may not be able to access the xhdpi directory is if the device is running in screen compatability mode:
Android - Extra large images placed in res/drawable-xhdpi aren't showing on tablet emulator, why?
Another possible reason is if your drawable is very small and one of its dimensions is rounded to zero as a result of scaling:
Android resource not found because of width and height
Finally, it is possible that some OEM versions of Android may implement this in a non-standard way (e.g "enhancing performance" by not searching the xhdpi directory if their device is hdpi):
Android Drawable hdpi xhdpi mdpi ldpi concept
You should keep your drawables in the hdpi folder. Since the phones that it doesn't work on have less pixels, they can't show the image. Just relocate the files.
Edit: They have less pixels because they have a smaller screen size.
i am attempting to get my android app to work on both phone type devices and tablets. for the layouts i have layout-normal and layout-large and i place my xml files inside each and it seems to select the correct one for each device (layout-normal for phones and layout-large for tablets).
however the problem arises for the drawable folders. i have drawable-hdpi, drawable-mdpi and drawable-ldpi. the tablet is taking its images from the drawable-mdpi, and the phone is taking its images from the drawable-hdpi. from the reading i have been doing this seems to be backwards??? this seems to happen on both the emulator and real devices, could i be doing something wrong? am i mixing something up?
Clayton,
drawable-hdpi and drawable-mdpi is not related to the size of the screen itself, but to the resolution of the display.
It's probably easy to think in terms of the iPhone 3GS and 4 for this (bear with me please). The 4 has retina display, hence a much higher resolution. Using the same sprites you'd use with the 3GS would result in a blurry display.
Android phones are, if anything, much more diverse in terms of screen options.
If you want to be able to aim different layouts at different resolutions, please try putting the layouts into /layout-xlarge, /layout-large, etc...
You can find more here:
http://developer.android.com/guide/practices/screens_support.html
There are some changes that you can see for Android 3.2 and above:
Beginning with Android 3.2 (API level 13), the above size groups are
deprecated and you should instead use the swdp configuration
qualifier to define the smallest available width required by your
layout resources. For example, if your multi-pane tablet layout
requires at least 600dp of screen width, you should place it in
layout-sw600dp/. Using the new techniques for declaring layout
resources is discussed further in the section about Declaring Tablet
Layouts for Android 3.2.
ldpi, mdpi, and hdpi refer to pixel density, not screen size.
The accepted answer does not address a serious problem: if you have many drawables, you end up with an unnecessarily big apk file because of resource duplicating. The only solution for that is the resource alias option described here:
http://blog.evendanan.net/2011/03/Android-resources-and-device-fragmentation
Edit: I just beheld that OP didn't realize that most phones have hdpi density, while most tablets have mdpi density. At the same time the tablets mostly have higher resolution. Hence Android will use smaller pictures for higher resolution.
You can overcome this only by using vector images or using the methods described in the accepted answer and in my answer.
drawable-hdpi - application use this drawable images when the device has high pixel density
drawable-mdpi - application use this drawable images when the device has medium pixel density
drawable-ldpi.-application use this drawable images when the device has low pixel density
Some of users downloading my apps complain that they were unable to install the app as it exited with MainActivity.class layout not being found. After investigating, I realized that those mobile phones have unusual screens.
For example, one of those phones is HTC ChaCha which screen is 480 x 320 pixels, 2.6 inches (~222 ppi pixel density). According to these specifications, it is a Normal screen, MDPI.
However, as its screen is set in the landscape mode (wide mobile screen), Android does not recognize it as Normal MDPI, but as something else and then it tries to pull XML layout from /layout dir. The Main.xml layout in this directory does not envisage such unusual screens and the layout gets broken (layout icons too big and probably pulled from HDPI drawable directory).
How to make the XML layout for such unusual phones?
PS. One more Question. When I create an emulator for this phone via Android SDK Manager, should I set "Abstracted LCD density" to 222 or keep it to 160???
The problem of the HTC Chacha is in fact it's screen aspect.
It's a "notlong" screen (like the HTC Wildfire if I'm correct).
To make a specific layout for this phone (and all screens with a 4/3 ratio), just make a layout in layout-notlong directory.
res
|---layout-notlong
|----mylayout.xml
Are you sure that the error is that the activity's class can't be found?
Several device vendors will incorrectly describe the density of their screens. The density is not derived from the physical size and pixel count. Some have done this for compatibility reasons; for instance, the original Samsung Galaxy Tab (released before Honeycomb, therefore not technically "tablet ready") reports itself as HDPI so that graphics and layouts are selected to make it use the screen more like a phone.
In regards to your layouts, if you have a decent default (in res/layout/) this will be chosen if no more specific layouts are available (e.g. res/layout-land/ or res/layout-large/). Keep in mind that each of the view ids that you reference in code must be available in all layouts. Keep them all up to date with each other or you will end up with inconsistent behaviour.
If you're diligent about making graphics for at least the main three densities (ldpi, mdpi, and hdpi) then you should not see over-large icons except where the screen is physically smaller than your layout expects it. Also, use dp in your layouts instead of px.
Perhaps the good start to identify the problem is to check the Application Error Reports
in your android market publisher account.
Click on Erros(2) just next your app in the apps listing.